アドベントカレンダー3日目
リリカルです。前回の続きです。
前回は「テスト計画について調べていたら、テスト要求という別の単語が現れた」というところまで行きました。いったいいつになったら分析・設計の話に入るのでしょうね
なので、今日は「テスト要求」とは何か探っていきます。
テスト要求について書籍をあたってみる
さて、では早速テスト要求について書の記述を見ていきましょう。(中二病風に言ってみました)
見つからない…
見つからない…
あれ?もしかして…
テスト要求っていう用語、正式な用語じゃないのかな?
ISTQBの用語集にも、「テスト要件」という単語はありますが「テスト要求」という単語は載っていません。困りました。テスト要件は、明らかにテスト要求とは違います。
なので今回は方向を少し変えて、まず「要求分析」というソフトウェア開発における用語に置き換えて調べてみます。そのあとで、テストに読み替えるとどうなるか考えることにしましょう。
まずは安定のSQuBOK(第二版)先生に聞いてみると、それらしい記述が見つかりました。ここでは簡単に説明しますが、(詳細な記載はSQuBOKで「要求分析」で索引を引いてみてください。) 要するにここでいう要求とは「目標、ドメイン知識、ステークホルダー、稼働環境、組織環境などからの要求」のことです。目標というのはおそらくビジネス的な目標などでしょう。これをテストに置き換えると以下のようになります。
テスト要求とは、ビジネス的な目標、ドメイン知識、すべてのステークホルダー、テスト/開発環境、組織環境などからテストに求められる要求のことである。
(リリカル的定義)
テスト要求について、なんとなく理解できたでしょうか。
ここで、前回のテスト計画の定義を再掲します。
今回やろうとしているテストでは何が大事で、どういった要求があって、使用できるリソースや想定されるリスクまで勘案すると、どういうテストをどういった方針で実施していくべきか考えることが、テスト計画であるといえます。
(リリカル的定義)
つまり、テスト計画のインプットの一つとして「テスト要求」が存在します。要求抽出の方法は様々ありますが、その方法は先のSQuBOKの記述の通り漏れなく間違いのないようなやり方を考える必要があります。
ここまでを軽くまとめると以下のような形になります。
テスト要求抽出→テスト計画→テスト分析・設計
(ここまでの説明をまとめただけであり、このプロセス自体の整合性は保証しません。念のため)
ここまで来て、なんとなくリリカルの意図が理解できた方もいらっしゃるかもしれません。
私は、「テスト分析・設計はこれだ!」と簡単に説明できるとは正直思っていません。
テスト分析・設計はあくまでテストプロセスの一部でしかないからです。
なので、テストプロセスは全体としてどのようなプロセスで成り立っていて、それにはどういった意味があるのか。その中で、テスト分析・設計はどういった意味を持って存在しているプロセスなのか。そこまで理解して初めて、なんとなく感覚的にテスト分析・設計についてつかめるような気がしています。
次回は、テスト分析・設計のあとに何のプロセスが来るのかを考えてみたいと思います。遠回りのような気がしてモヤモヤするかもしれませんが、あと少しです。
次回もお楽しみに。