MasaoApril's Library.

Software Testingなネタを書いてみた。

JaSST'13東海SIG(17) 「どのような時に探索的テストを実施すればよいのか?(前編)」

JaSST'13東海SIG(16)からの続きです。

SIGでの議論内容(2)

 前回の議論内容は、「テストチャータの役割」についてでしたが、今回は開発背景の切り口で「どのような時に探索的テストを実施すればよいのか?」の議論について前編として紹介します。

どのような時に探索的テストを実施すればよいのか?

開発背景

状況
  1. タイミング
  2. 社内政治
  3. バグ曲線

 開発フェーズの進行に対し、テスト側がプロジェクトに参入する時期は、予算の関係や参入前のプロジェクト対応状態(開発遅延発生/計画通りなど)により、キックオフ時/外部仕様書作成中/.../統合テスト実施中/システムテスト実施中/...とまちまちです。

 社内政治にも左右されますが、テスト対象のプロダクト品質が要改善であるとき、品証部門から統合テスト実施時の信頼成長曲線の変化を見て、

 「潜在バグは本当にないの?」

 「統合テストで○○件のテストケースを完了したけど、不具合は□□件あるが、バグは収束したと言えるか?」

と問われる場面があります。

 1つの案として、「追加テスト実施」で『スクリプトテスト実施時に手薄になっている機能』や『インシデントレポートでバグ指摘で挙がった機能』をテストチャータとして作成し、(スクリプトテストと並行して)探索的テスト実施を開発マネージャへ提案することも作戦の1つです。

工数

 開発費用の関係やプロジェクトの進捗状況により、予想外の設計工数増大のため、テスト工程が縮減されることが多々あります。当然、計画されたスクリプトテストの実施件数は全件実施が不可能な状況になります。そのため、スクリプトテストの実施件数を残された工数分剪定する形で減らしますが、スクリプトテストの内容をベースに即興の探索的テストを実施し、スクリプトテストを補うことも戦略として考慮するとよいでしょう。

品質要求

 製品の用途や特性により品質要求は異なりますが、例えば人的危害が無い異常は停止させずに継続して動作させる製品の場合「エラーが発生しても、○○機能が停止しないこと」、つまり『信頼性』や『障害許容性』が求められます。

 探索的テストを実施する際、『信頼性』や『障害許容性』をキーワードとして、「△△な外乱があっても、○○機能は動作し続ける」ことを確認することも効果的に探索的テストの成果を出す1要素になります。

 次回は、「どのような時に探索的テストを実施すればよいのか?(後編)」について書きます。