BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Kyle McMeekin氏,テストの現実的課題を語る

Kyle McMeekin氏,テストの現実的課題を語る

原文(投稿日:2016/11/04)へのリンク

先日のAgile 2016カンファレンスでInfoQは,Kyle McMeekin氏と,アジャイル開発におけるソフトウェアテストをめぐる現実的問題,テストの自動化を推進する活動,さらには探索的テストがスクリプトによる手動テストとどのように違い,いかに効果的か,などについて語り合った。

infoQ: Kyleさん,簡単な自己紹介と,QASymphonyについて説明をお願いします。

QASymphonyは,より高品質なソフトウェアの開発を支援するソフトウェア会社です。アジャイルのスタンスを取る,あるいはアジャイル方法論への移行に取り組むチームや組織,企業を支援し,QA部門がアジャイルへの取り組みを成功させるためのソフトウェア製品を提供します。QASymphony内での私はシニアプロダクトエンジニアとして,当社の所有するさまざまな製品の習得支援やデモ製品を提供し,組織のプロセスないし活動を当社製品にフィットさせるために顧客チームと共同作業を行なう上で,基本的な責任を負っています。

InfoQ: あなたが実際に市場で見た現実世界の問題には,どのようなものがありますか?

アジャイルへの移行に関わるメンタリティの問題ですね – 問題の総称と言ってもいいでしょう。移行に取り組みながら,“さあ,アジャイルを達成したぞ”,と言うチームをよく見かけるのですが,それは何を意味するのでしょう?私は月に数百という顧客と話をしていると思っていますが,その度に違う定義を聞かされます。ですから私は,チームがアジャイル活動を成功させる能力と,そのためのツールスタックを提供する必要があると考えています。当社が関わる組織では,多くの場合,開発チームのアジャイル移行が先行しています。彼らはJIRAやRally,VersionOneといったアジャイルALMを採用した上で,あたかも孤島にいるような自分たちに問いかけるのです,“もっとアジャイルになるためには,何をすればよいのだろう?”と。

多くの場合,次には自動化を推進することになります。手動テストの実施によって自らがボトルネックにならないために,テスト自動化の方法を探すのです。開発チームが自動化を推進する上では,これが大きなイニシアティブになっていると思います。加えて最近よく耳にするのが,探索ベースのテスト(exploratory-based testing)です。とはいっても,テスタや品質担当者が実行するテストのステップには,探索ベースのテストは実際に含まれてはいませんから,ウォーターフォールベースのアプローチのように,スクリプトを用意した上で,多くを手作業で実行することになるかも知れません。“ステップ1は間もなく完了するから,次はこれを実行しよう”というように,一連のテストを形式的に行なうのです。

探索ベースのテストは,チャータセッションを行なうことでより大きな効果が得られます。あなたが持っている製品知識を使って,アプリケーションの動作をくまなくテストするのです。そうすれば,むやみにクリックして回るのではなく,ちゃんとした理由を持ったテストが行なえます。個人の知識を前提とするのです。“管理者になって,エンドツーエンドのユースケースを一通り実行する。具体的には,Amazonでアイテムをチェックアウトしてカートに追加し,請求先情報を入力して ...”,というのは,しかし,あなたが実施するという前提に立ったものではありません。そういったユースケースを一通り実行するには,別の方法があるはずです。

テスト的な観点で言えば,おそらくは1回のスプリントでどれだけをカバーできるかという意味であって,こういったものがテスタを支援する力になると思います。テスタの作業は手動テストに制限されたり,あるいはそれを元に叱咤されるようなものではありません。彼らの役割はひとつでも多くのバグを見つけ出すことであり,最終的にそれらが運用段階に持ち込まれることのないように,テスト段階で検出ことにあります。

InfoQ: 単にランダムにクリックをするのでないとすれば,どういうことになるのでしょう?探索のチャータをセットアップするにはどうすればよいのですか?

一般に探索ベースのテストを実施するには,事前に記入しなくてはならないフィールドや要素がたくさんあります。まず,目標があるはずです。このテストを実施する上で,自分が求めている目的は何か?その中で私の役割は何か?何らかの前提条件は存在するのか?そして最後に,報告があるはずです。どうやってセッションを終了させるのか?あなたが行なったテストの方法の中で,仲間や同僚ならばおそらくは行なわなかったものは何か?

私がいつも考慮するようにしているのは,その方向性という面です。つまり,WazeやGoogle Mapsを例にするならば,開始位置をポイントAとしてポイントBに向かおうとする場合,この2つのアプリケーションの示すルートが違っているかも知れません。そこで,“建造物の関係から,この地域は避けておこう”とか,あるいは“5マイル遠くなるけれど景色がいいから,こちらの道にしよう”といったことが起きるでしょう。

最終目的に到着するための方法はいくつもあります。探索ベースのテストについて考える場合,これがもっとも分かりやすい考え方だと思います。ポイントAからポイントBに行くためには,道から外れてさえいなければ,何も鉄道でなくてはならない理由はありません。ですから,例えばユーザがアプリケーションをテストするのにも,さまざまな方法があるのです。このような決められた簡単な方法を,いつも行なう訳ではありません。このような詳細を理解した上で,セッションで目標とするものに取り組むことが何よりも重要だと思います。そして最終的には,テスタにこの役割を果たしてもらうのです。そうすることによって,手作業でのテストケースの場合のように事前に用意されたスクリプトをベースとした定義済みのテストを実施するのではなく,彼らが自分自身でさまざまなユースケースを考えられるようになります。

InfoQ: この方法でもっと多くのバグを見つけられることが証明されている,という発言がありましたが,それについてもう少し詳しく話して頂けますか?

私たちQASymphonyではそれに関するウェビナを実施したり,スライド資料を取りまとめたりしています。私自身は直接関わっていませんが,当社の所有する探索ベースのテストツールを実際に活用すべく顧客とともに取り組んだ,いくつかのケーススタディがあります。その中で述べられているのは,全体としての満足度,テスタの仕事の満足度,彼らが実際に達成して,外部に対して貢献ないし証明できた付加価値などです。この件に関する調査の詳細については,こちらで公開していますが,極めて大きな成果です。この領域にはさまざまな思想的リーダが数多く存在していますが,中でもDavid Cummings氏は重要な思想的リーダのひとりで,価値提供や探索的テストが提供できるものについて多くを語っています。

InfoQ: 私たちに話をする時間を割いて頂いて,ありがとうございました。

こちらこそ。

インタビュー回答者について

Kyle McMeekin氏はQASymphonyのシニアプロダクトスペシャリストとして,提供製品のユーザ向けデモンストレーションや技術サポートを中心に活動しています。氏はかつてCognizant Technology Solutionsでテスタとしての時間を過ごし,ワシントンD.C.でキャリアを積んだ後にアトランタ地方に移動しました。氏は熱心な技術愛好家であると同時に,筋金入りのMichigan Wolverinesファンでもあります。

 

 
 

この記事を評価

関連性
スタイル
 
 

この記事に星をつける

おすすめ度
スタイル

BT