アドベントカレンダー８日目
リリカルです。前回の続きです。
前回は「テスト分析のアウトプットはテスト分析手法によって様々である」というところで終了しました。
マインドマップ、マトリクス、テスト観点図…
どれか一つが正解ということはありません。
テスト分析のアウトプットが満たしているべきこと
では発想を変えて、テスト分析のアウトプットが満たしているべき条件を挙げていきましょう。
テスト条件の識別に活用できること
これは大事です。なぜならテスト分析の目的そのものだからです。
あれ？もしかしてこれさえ満たせばよいのでしょうか？
イマイチなテスト分析のアウトプットとは
では逆に、アンチパターンを考えてみましょう。きっとこちらの方が簡単ですね。
1. 分析の結果、テスト条件が漏れている
テスト分析した意味がありませんね…良くないパターンです。
2. 一覧性がない
ぱっと見でテスト条件の全体像がつかめるようになっていることが大切です。一覧性がないと、テスト条件が漏れていたとしてもそれに気付きづらいです。
3. テストの優先度・重要度などを表現できていない
テスト条件には優先度や重要度があります。これを表現できていないとテスト分析のアウトプットとしてはイマイチです。
4. テスト条件同士の関連を表現できていない
テスト条件間に関連があった場合、それも表現できると良いでしょう。
5. 仕様書の問題点を指摘するのに役立てられない
テスト分析というのは、インプットとして仕様書などを用います。これはテスト分析が静的テストの性質も持つことを示します。というのも、仕様書はあくまで開発者が開発を進めるための成果物として作成します（それ以外の目的もあるかもしれませんが、主目的は開発に必要だからのはずです）ので、それを「何をテストしたらいいか」「どうやってテストできるか」などと検討することはいわば試験性という別の観点から仕様書のレビューをすることになります。
つまり、テスト分析のアウトプットが仕様書の問題点を指摘するのに非常に役立つということです。逆に言えばそれができない場合はテスト分析が不十分であることが多いです。（完璧な仕様書が作成されていれば問題点も何もないのかもしれませんが、一般に開発者が仕様書を作ると試験性の観点からは検討が漏れてしまいがちです。なぜなら開発するときの頭の使い方と、検証するときの頭の使い方は根本から異なるからです）
なんとなく、アウトプットのイメージはわいてきたでしょうか。それで、改めてテスト分析のアウトプットとして挙げられる「マインドマップ」「マトリクス」「テスト観点図」などはこれらの条件をクリアしていることが多いです。というのも、テスト分析の目的に沿った表現方法を選択しているからです。少なくとも、テスト分析のアウトプットが文字の羅列では良くないということがわかるでしょう。
テスト分析を３行でまとめてみた
さて、いよいよテスト分析編のまとめです。
テスト分析を３行でまとめるなら、
テスト対象に関する情報とテストに対する要求をもとに、テスト条件（何をテストすべきか）を洗い出し、テスト条件の全体像、優先度（重要度）やテスト条件同士の関連をモデルや図を用いて視覚的に表現すること。
となるかなと思います。静的テストは主目的ではなく副次的な効果です。
テスト要求って言葉がかなり広いので、３行で書いてはいますが実際は色々なインプットがあってアウトプットもしっかり考えないとうまくいきません。（体験談）
ふう、やっとテスト分析についてはひと段落つきました。次はテスト設計です。ガンガン行きます。それではまた次回。
追伸
「今北産業その８」というタイトルはさすがに微妙すぎるので、ちょっと付け足しました。
