【探索的テスト】④テストチャーター その1

前回は探索的テストの情報収集でした。

さて、いよいよテストチャーターです。
テストチャーターは、「テスト目的」を定義したしたものです。
くどいようですが、探索的テストとフリー/アドホックテストは別物で、
「テスト目的/ゴール」の為にテストをすることについては、スクリプトテストと変わりはないです。
ただ「テストケースを書かない」「テスト設計を実施と並行して行う」の違いがあるため、
テストチャーター(目的)までの抽象度で記載をとどめます。

さて、このテストチャーター、どのくらいの粒度で書くのがよいのか?
非常に悩ましい問題です。

以下、抽象度によってのメリット/デメリットを記載してみます。

★粒度:粗い
<メリット>
・テスターが観点に囚われず自由にテストができ、スクリプトテストでは気づきにくいバグが検出しやすい
<デメリット>
・テスターのレベルによって、テスト内容の決定が難しい場合がある
・バグやインシデントの分析に時間がかかる

★粒度:細かい
<メリット>
・テスターのレベルによらず、テスト内容を決定しやすい
・バグやインシデント発生時、原因や弱点を分析しやすい
<デメリット>
・テスターが記載された観点内で狭いテストを実施してしまう

・・・まあ、簡単でなことです。
詳細に記載しちゃうと、ある程度探索範囲の指示ができますが、
範囲が狭くなって「探索」できなくなります。

上手い粒度を探っていくしかないです。
テスターのレベルやテストの目的に応じて調整していくのがよさそうです。

以下は日本ナレッジ風「NKC探索的テスト」の方法です。
(これが正しい探索的テストのやり方という訳ではないですのでご承知を)

最終的には、こんなマトリクスを作りたいです。
↓↓↓↓↓↓

縦軸がテスト対象(探索範囲)で、横軸がチャーター(探索目的)です。
探索範囲の中を目的を持って「探索」するイメージです。

さて、では縦軸を検討しましょうか。

<縦軸の検討>

探索的テストとはいえ、網羅はある程度確保して
トレーサビリティも保ちたいので、仕様書をベースにすることが多いです。
(当たり前ですね)
ただ、仕様書がそのまま使えるわけではない場合も多いので、その場合は
機能分析してテストしやすい粒度に再構築する必要があります。
・機能一覧
・画面一覧
・要件一覧
などはそのまま縦軸に持ってきやすいです。これも当たり前ですが。

あとは、ユーザー観点の試験にするなら
・ユーザーストーリー
・シナリオ
などもありますし、目的によっては色々だと思います。

弱点強化試験風に出荷直前に行うなら、不具合情報から
テスト対象を絞ったり検討することも有りと思います。

長くなってしまったので、続きは次回。
横軸(目的)の検討の予定です。