前回の記事「チャレンジ！『探索的グレーボックステスト』#1」でも説明しましたが、『探索的テスト』は特に規格定義はなく、決まった手順もありません。今回は『探索的テスト』をどのように進めるかのポイントを説明します。自分たちの製品開発に合ったガイドラインを考えてみてください。

『探索的テスト』の進め方

何事も段取りは、重要です。テストケースを用意せずに、素早くテストが開始できる『探索的テスト』だからと言っても、効率・効果をより向上させるためには、事前準備が重要となります。

知識や過去の知見をもとに、戦略や戦術を準備しておかないと、行き当たりばったりのテストになってしまいます。バグを探り当てる「探索」的ではなく、危険を冒す「探検」や成功のおぼつかない「冒険」といった無謀なテストになりかねないので、注意してください。

●準備

まず『探索的テスト』のテスト観点を明確にします。テスト実施で達成したい目的やゴール、そのためのテストチャーターを用意します。テストチャーターは、目的達成のための方針や目印といったものになります。また、テスト終了についても、終了とする条件や状況を事前に決めておくのが望ましいです。

図1 テストチャーターの例

マイクロソフトの開発者向けサイトにおいて、テストチャーターをさまざまなツアープランに例えて紹介している投稿記事が参考になります。

探索的ソフトウェアテスト
http://msdn.microsoft.com/ja-jp/library/jj620911.aspx

探索補助のために参考とするドキュメントとして、類似プロジェクトや前工程までのバグの傾向やバグリスク管理情報を用意しておきます。こうした知見が、探索時の思考力を活性化させ、効率的にバグを見つけるテストアイディアを生み出すことになります。

●実施

まずスモークテストとして、正常系代表的なテストを実施します。このテストが正常に実施できるまで、以降の手順は実施しません。最初のスモークテスト(前回のテスト)をふまえて、バグが潜んでそうなところを探ってさらにテストを進めます。
どのようなテスト観点でテストを実施したのかを、マインドマップで簡単にメモとして記録しておくとその後の作業を効率よく行えます。再テストする場合の手順にもなり、製品に対する新たなテスト観点やテストケースを創造するための思考を支援します。メモがそのままレビューにも活用でき、ノウハウの共有も容易です。無駄になるドキュメントは作らないのが『探索的テスト』の目的の一つなので、必要な情報をできるだけ簡単に管理する工夫が必要となります。

図3 マインドマップの活用 (探索的テストをしながら、抽出した観点やバグの潜伏箇所をチェック)

●報告

テストを実施し、バグと思われる事象を確認したら、バグの解析を行います。解析が困難なバグの場合、後工程へのリスクとなるか？検討の上、リスクとして管理します。バグと判断した場合は、本来どのテストで抽出すべきバグなのかを確認の上、バグ管理をします。開発者がコードを修正したら、回帰テストと再テストを行います。
また、不具合発生件数から製品のソフトウェアの弱みを把握し、テスト計画を見直します。

自分たちのやり方をみつけよう

『探索的テスト』のイメージをより具体的に掴んでいただましたか？
最初は場当たり的なテストになってしまうかもしれませんが、その手法やデータを蓄積して、徐々に明文化や見える化をすることで、創意工夫できる要素が見えてくるかもしれません。やり方はひとつではありません。『探索的テスト』のアプローチをふまえつつ、自分たちにとって効率の良いやり方を確立していきましょう。

次回は、『探索的テスト』の弱みを改善するための『動的テストツール DT10』の活用を考えていきます。

ハートランド・データの動的テストツールをぜひお試しください。

無料のトライアルをご用意しています。
－ 「動的テストツールDT+」の詳細はこちらから －

---

＜参考文献＞

高橋寿一「知識ゼロから学ぶソフトウェアテスト【改定版】」翔泳社
テスト技術勉強会 井芹 洋輝「探索的テスト入門」
株式会社NTTデータ 熊川 一平　「探索的テストを活用したシステム開発手法の提案」
Microsoft　探索的ソフトウェアテスト http://msdn.microsoft.com/ja-jp/library/jj620911.aspx