質問: 単体テストや結合テスト、総合テスト全般についての質問ですが、どこまでテストを行えばいいのかが分かりません(どんなテストケースを作ってテスト仕様書をかけばいいのか分かりません)。 テスト仕様書自体は作成することができますが、本当にこれで全て網羅しているのか不安です。 何かアドバイスをいただきたいです。
回答: Vモデルの考え方を基本にマトリクスとデシジョンテーブルを活用すると良いと思います。 どんなテストケースを作ってテスト仕様書を書くかについては、基本はVモデルに従います。 規模の大小やプロジェクトの進め方が違っても結局はVモデルの考え方が登場します。 テスト仕様書のインプットはテストの工程に対応する設計書だということです。 本当に全部網羅しているかについては、網羅性が見えるようになれば安心感を得ることができます。 テストパターンの洗い出しにマトリクス表を作り、 テストパターンに対する結果の抽出にはデシジョンテーブルを作る と良いと思います。単純作業に近いので取り掛かりやすく且つ分かりやすいでしょう。 (単純なだけに爆発的なパターン数になります。実質不要なパターンも数に含まれるので冷静に見ましょう) 単体テスト、結合テスト工程においては実際にコードが動いた実績の確認も行うと良いです。Carimaticsさんも回答されているカバレッジの確認です(昨今のプロジェクトでは必須?)。カバレッジ100%にこだわらないほうがよいという考えに賛同します。100%にするためにテスト対象のコードを変更しなければならない場合が存在します。100%にするためにテスト対象を変更しては意味がなくなってしまいます。かといって設計変更はインパクトがある。この場合はテストできない理由を記録し残します。カバレッジはトータルでは100%になることはないと言えるかもしれませんね。 蛇足ですが、Vモデルの考え方はテスト工程で設計工程の記述不足・検討不足をあぶり出すことになったりします。設計そのもののテストにもなっていると言えるでしょう。こうしたものを見つけた場合には懸案事項や課題管理表に記録し報告するようにすると良いでしょう。 (工程が終わっていたり、契約上設計書を変更できない等で受け入れられない可能性が高いですが、こうした活動は次の改善になります。)