【探索的テスト】③情報収集

導入の検討も終わり、「探索的テストでいこう!」となりましたので、
さっそく探索的テストに必要な情報を収集します。
ただ、何度も述べているように、基本は「テスト項目を簡略化」というだけの事なので
通常のスクリプトテストと大差ないと考えます。
とはいえ、テスト目的が「網羅」よりも「ピンポイント」に極端にシフトするので、
「アタリをつける」ためのインプットが重要になると思います。

インプットは大きくは二つ

①以前のバージョンなどの情報(過去)
-不具合情報
-QA(質問・課題)情報
-テストケース仕様書など

②テスト対象自体に関する情報(現在・未来)
-要件一覧
-各種仕様書

「問題が検出できそうな箇所を狙い撃つ」(または「不具合が出た時にインパクトが大きい箇所を狙う」)という目的を考えると、
①の既に起こっている事(=過去)の情報を重視するのが良さそうです。
過去の不具合や問題点などを分析する事は有効ですし、あらかじめそれらが
情報としてまとまってあれば使いやすいと思います。
(例)いわゆる「テスト観点一覧」みたいなもの

また、②の「現在・未来」に関しても、仕様書などから読み取れる情報にて
「あやしい」部分を見つけておきます。
-仕様の疑問点(たとえば境界値不明、、、など)
-考慮されていない品質特性
-不具合時に周りへの影響が大きそうな機能

少し話は飛んでしまうのですが、「アタリをつける」方法として非常にシンプルなのが

不具合が検出しやすそうな
【機能】×【観点】

で分けて考えると良さそうです。

【機能】については分かりやすいですね。
例えば
・過去にバグが頻発していた機能
(のうち、今回の開発に関連するもの)
・不具合が発生した場合、影響範囲が大きい機能
・不具合が発生した場合、リスク(発生確率×インパクト)が高い機能
などです。

【観点】とは、非常に抽象的ですが、今回はシンプルに
「機能に対するアプローチ」
くらいにとどめておきます。
例えば
・機能に対する「手順(操作/トリガー)」
・機能に対する「入力データバリエーション」
・機能に対する「品質特性」
これらを、過去の不具合資料などの傾向資料からピックアップしていきます。

その他、前述した「機能に対する疑問点」も有効な情報になりますね。
例えば
・境界値が仕様に書かれていないのでは?⇒機能に対する境界値を考慮
・高負荷状態の動作が考慮されていないのでは?⇒機能に対する高負荷試験実施

先ほども書きましたが、汎用的な観点一覧を作っておくと良いです。
ありがちですが、ウチのチームが使ってるWEBの観点一覧の例。

粒度感はなかなかに難しいのですが、ある程度の対象ドメインに汎用的に使えるように
抽象度を調整する必要があります。(これが結構難しい)
※なるべく「対象機能に依存しない」記載が良いと思います

という事で、こういった一覧から、今回の試験向けにピックアップや精査を行い、
「観点」を決定していきます。
同時にテスト対象の「機能」も決定していきます。

これにより
【機能】×【観点】
の構造が出来上がります。

たとえば

「仕様書や要件一覧を見ると、画面Bは重要機能だなあ」=【機能】

×

「過去にこのシステムではブラウザ互換で不具合が多かった」=【観点】

「画面Bのブラウザ互換試験の実施」

ですね。

ここからもう少し詳細化していくのが「テスト設計」になると思いますが、
今回のテーマは「探索的テスト」ですので、このままの粒度感でテストを実施します。
具体的には【観点】を【テストチャーター】にまとめ、マトリクス化するところまでの抽象度で
試験を実施します。

「テストチャーターってなんだ?」
「どうやって作ればいいんだ?」
「どうやってテストするんだ?」


はまた次回。
(重いテーマですね・汗)