アドベントカレンダー６日目
リリカルです。前回の続きです。
いよいよ今回は本題の「テスト分析・設計」がいったいどんなプロセスのことを指すのか考えていきます。
前回までのおさらいをすると、以下のような流れでプロセスがあるというのがわかってきています。
テスト要求抽出→テスト計画→テスト分析・設計→テスト実装
テスト計画で決めた大まかなテストの実施方針にしたがって、テスト分析・設計を実施し、テスト実装の元ネタであるテスト観点など（＝高位レベルテストケース）を導いていきます。そのプロセスを深掘りしていきましょう。まずは「テスト分析」から先に考えていきたいと思います。
以前私も、テスト分析手法である「ゆもつよメソッド」を学習した時に「テスト分析」とは何か考えたことがあります。以下がその記録です。今から考えるととても恥ずかしい内容ですが…
テスト分析についてなんとなくわかった気がする - 自分、燃えてるんで。
テスト分析はどうやらテスト対象分析だけではダメで、テスト要求分析も必要らしい - 自分、燃えてるんで。
最初、僕はテスト分析のアウトプットとしては「ソフトウェア仕様を理解・整理したもの」みたいなのを想定していました。要するにソフトウェア仕様をモデリングなどしてより深く理解することをテスト分析の目的と認識していたのです。しかし、識者の方々に意見を伺うとどうもそうではないということがわかりました。テスト分析にはどうやらテスト対象の理解・分析の他に「テスト要求の理解・分析」が必要らしいのです。
テスト要求分析が必要というのは、特にテスト実行者からは理解しづらい
テスト要求には往々にしてマネージャの考えること、すなわちビジネス要求やリソース的な制約などが含まれます。
テスト実行者は、日々そういったことに目を向ける機会は比較的少ないのではないでしょうか。気をつけてはいても、どうしても目の前のプロダクト、仕様書に目がいってしまいがちです。その結果、テスト分析のアウトプットは仕様書を理解・整理した結果であるというちょっと足りない定義に落ち着いてしまうこともあります。
次回：テスト分析のインプット・アウトプットとは何か
次回は、改めてテスト分析のインプット及びアウトプットは何なのかをより深く考えていきます。今日は少し早いですが、ここで一度区切りとします。
