【探索的テスト】導入の検討②(なにを目的とするか?)

前回のエントリでは、導入のタイミング(フェーズ)について記載しましたが、
そもそも、探索的テストに向くテストと向かないテストがあると思います。

○探索的テストに向く場合
→仕様変更が多く発生する可能性が高い場合
※機能やチャータをある程度抽象化することにより、仕様変更への対応がしやすいと思います
→使用性の問題を発見したい場合
※スクリプトテストでは事前に考慮しづらい、使用性のテストには「対話型」である探索的テストは効果的と思います
→スクリプト試験を実施したあと、テストケース外の動作の確認をしたい場合
※スクリプトテストで拾えないインシデントを発見する目的です
→テスト対象の品質状況をまずは調査したい場合
※スクリプトテストの前に実施するパターン。スモークテストの意味合いに近いかな

○探索的テストが向かない場合
→品質がとても安定しているアプリ
※探索的テストに限ったことではないのですが。ただ、探索的テストの成果が
「不具合の発見」に依存してしまうので、効果が内容に見えると思います
→網羅性やエビデンスを要するテスト
※ドキュメント作成を極力省きますので、当然といえば当然
→性能等の非機能テスト
※ドキュメントを書かないメリットは少なく、手順が定まっているために探索効果は薄いと考えます

おおむね、これらを考慮して方針を策定することが多いです。
方針の内容は大まかに以下にします。

1、探索的テストが必要と判断した理由
2、探索的テストの目的(狙い)
3、インシデント判断基準
4、スケジュール(期間と工数)
→準備(対象分析)
→チャーター整備
→実施

これらをレビューにて確認して、合意します。
計画書に記載してレビューすることもあれば、打ち合わせの段階で
上記合意していく場合もあるかな。
1~3は実は一連のつながりを持っているので、どこまで詳細化するかは
場合によるかも。