JaSST'13東海SIG(18) 「どのような時に探索的テストを実施すればよいのか？(後編)」
SIGでの議論内容(3)
(2ヶ月半のブランクがありましたが)前回は、「どのような時に探索的テストを実施すればよいのか？」の議論(前編)でしたが、今回は「どのような時に探索的テストを実施すればよいのか？」の議論(後編)を紹介します。
どのような時に探索的テストを実施すればよいのか？(後編)
・ミッションクリティカル系
<意見>
- やらないほうがよい
- 絶対NGとはいえない
SIG参加者の開発ドメインが様々でしたので、意見が二手に分かれました。
1.の「やらないほうがよい」という意見は、SIGの議論内容やこれまで多くの方と話した傾向から、
『ステークホルダにテスト結果のエビデンスを提出する必要があり、(開発規定がある関係で)テスト結果が残らない探索的テストを公式に実施するのは厳しい。』
という現場があります。現実的な方法としては、スクリプトテストを補うために非公式に探索的テストを細々と実施することが挙げられます。
2.の「全体NGとはいえない」という意見は、スクリプトテストを計画通り実施したが、念のためバグが潜んでいないか確認することを目的に追加テストとして実施することがあります。
個人的な意見ですが、ステークホルダにテスト結果のエビデンスを示すときは、
「スクリプトテストで発見したバグのインシデントレポートの一覧表」
を公式なエビデンスとして公式な形で提出し、
「スクリプトテスト以外で発見したバグのインシデントレポートの一覧表」
を補助のエビデンスとして非公式な形で提出もしくは追加情報として提供することをお勧めします。
・実施のタイミングは、いつがよいか？
<スクリプトテストの後>
- 探索的テストは、スクリプトテストを補う役割のため
- 文献によっては、「後」を推奨する記述がある。
1.は、知識ゼロから学ぶソフトウェアテスト 【改訂版】 高橋寿一(著)の「4.4章探索的テストのまとめ 図4-6 探索的テストのコード網羅率」によると、テストケースベースのテストよりも探索的テストの方が若干コード網羅率が改善でき、さらに開発者がテスト担当者にプログラム構造の情報提供するともう一回り改善できると言及しています。
組み込み系でありがちですが、人が微妙な時間で操作するときの絶妙なタイミングとして発生するバグがあり、ASICやFPGAの振る舞いとファームウェアの振る舞いを同時にスクリプトテストで事細かに記述するのは、限られた予算と工数の制約下では難しいです。しかし、探索的テスト実施時に設計情報をテスト実施内容に融合させると、テスト目的と手段が明確になるため、限られた予算と工数の制約下でより良い成果を出すことができると思います。
2.は、ソフトウェアテスト企業"BugHuntress QA Lab"社のblog記事"An Insight In The Ins & Outs Of Exploratory Testing"によると、「スクリプトテストで多くのバグを検出することができないときに探索的テストが大いに必要とされる。」(※意訳)とあり、スクリプトテストの後に探索的テスト実施すると解釈することができます。
<スクリプトテストの前>
・設計がグダグダなときに欠陥を検出するために利用
仕様書とソースコードと開発品の挙動が食い違ったり、何らかの単純な操作を行った直後に強制終了や動作が停止する開発品の場合、バグの発生原因を追及する必要があります。そのため、ある程度の当たりを付けることが必要です。スクリプトテストで当たりを付けるのは時間効率の面で非効率であるため、探索的テストを確保された工数でバグの傾向を掴むことも戦略です。
次回はSIGでの議論内容(4)として、「テストチャーターへ導くための分析」の議論について書きます。
