アドベントカレンダー７日目
リリカルです。前回の続きです。
前回は「テスト分析のインプット・アウトプットは一体なんなの？」というところで終了しました。
いつもはここで引用をしているところですが、今回は引用する部分があまりにも長くなりそうなので自分なりに本を読んで理解したところを書いていきます。
テスト分析をしないと何が困るんですか？
私の好きな質問のひとつです。それがないと一体何が困るのでしょうか。
簡単に言うと、私がテスト分析を行う理由は「テスト条件を識別するため（何をテストすべきか知るため）」だと思っています。なのでテスト分析がすっぽり抜けると、何をテストすべきなのか正確な判断ができません。結果として、的はずれなテストケースを作ることになります。よいテストにはならないと思います。逆に言うと、しっかりとテスト分析を実施して出てきたアウトプットはテスト条件を正しく認識するためにとても役に立ちます。
そして、何をテストすべきか知るために必要なのがテスト要求の分析とテスト対象の分析だと思います。
なぜ、テスト要求分析とテスト対象分析が必要なのか
何をテストすべきなのか知るためには、テスト対象のことを知らなければいけない。これは多くの人が理解できると思います。テスト対象の弱点であるとか、特徴や使われ方、具体的な仕様も知らなければテストすることができません。全部テストすりゃあいいじゃん、というのも当然現実的ではありません。（全数テストは不可能）
では、テスト要求分析はなぜ必要なのでしょうか。私も、以前はそんなのカンケーないだろと思っていました。ですが、これは何をテストすべきかに強く関連するのです。
テスト要求によってテスト条件は変わる
テスト要求にはどんなものがあるでしょうか。例えばリソースはこれくらいでやってほしいとか、テスターのスキルはこれくらいとか、実にテストマネージャには多様な要求が寄せられます。
それで、いつ何時もテスト対象分析の結果やりたいと思ったテストを100%実現できるかといったら、当然そんなことはありません。例えばですが、リソースが不足しているのに直交表を使って出てきたテストケースを全件消化しようとか、テスト初心者に「ドメイン分析をやって」などと指示したところでうまくいくわけがありません。これらは一種の制約条件ともいえるかもしれません。あるいは、顧客やPMから「この機能を重点的にテストしろ」と言われることだってありえます。それも当然無視することはできません。また、機能の優先度とか重要度とかがあらかじめ決まっていることもあります。バグの見逃しによるリスクの大きさから判断することもできます。
このように、直接テスト対象には関わらないけれども、テスト条件を識別するにあたっては必要になる情報というのは往々にして多くあります。それを、ひとくくりにして「テスト要求」という言い方をすることがあるのです。
テスト分析のインプット
テスト分析のインプットとしては、例えば以下のようなものが挙げられるでしょう。
- テストに関わるステークホルダーからのテストに対する要求を集めたリスト
- テスト対象プロダクト／システムの仕様書
- テスト対象に関するドメイン知識
- 要件定義書
- ビジネスプロセス
これらの情報を集めてきて、テスト分析を実施します。
テスト分析のアウトプットは何なの？
さてここが問題です。
というのも、テスト分析のアウトプットはおそらく、「これ」と決まったものがありません。
ただ、アウトプットは「テスト条件の識別」をするために作られるというのは同じです。ただ、どのような形をとるかはその人それぞれのテスト分析手法に依存するということです。マインドマップであることもあればマトリクスかもしれないし、あるいはテスト観点をモデリングした図かもしれません。
次回は、この「テスト分析のアウトプット」に焦点を当てていきたいと思います。
参考文献
ISTQBシラバス準拠 ソフトウェアテストの基礎
