V字モデルとは？開発工程とテストの対応を整理

V字モデルは、要求や設計を具体化する側と、その内容をテストで確かめる側を対応させて考えるモデルです。左側で「何を作るか、どう作るか」を掘り下げ、右側で部品からシステム、業務での利用へと確認の範囲を広げる形が、V字で表されます。

覚えたいのは図の形より、どの約束を、どの確認で確かめるかです。工程の名前は案件によって異なるため、名前だけでなく、テストの対象と根拠資料を合わせて確認します。

V字モデルでは、設計時からテストを考える

ISTQBのFoundation Levelシラバス2018 v3.1.1は、V字モデルが開発工程に対応するテストレベルを持ち、早い段階からのテストを支えると説明しています。ISTQBシラバス 2.1.1（PDF 28ページ）

「実装が終わるまでテストについて考えない」という読み方ではありません。プログラムを動かす時期より前に、要求や設計を読んで、期待する結果、必要なデータ、曖昧な点を確認できます。

例えば「権限のある担当者だけが一覧を取得できる」と決めるなら、権限のない人、権限が変更された人、ログインしていない人をどう扱うかも、設計時に検討します。

以下は業務システムを説明するための一例です。全社共通の工程名や、一対一の固定対応を示す規格表ではありません。実際には、同じ要件を複数のテストで確認することがあります。

ISTQBの同シラバスは、単体、結合、システム、受入を異なるテストレベルとして整理しています。本記事の日本語工程名は、読者向けに対応を示すためのものです。ISTQBシラバス 2.2（PDF 30ページ以降）

「基本設計に対応するのは必ずこのテスト」と名前だけで結論を出さず、その設計書に何が書かれているかを見てください。画面、連携、構成が一つの資料に含まれるなら、確認先が複数になることもあります。

説明用に、「管理担当が、対象期間の一覧をCSVで取得できる」という架空の要求を考えます。各テストは同じ操作を繰り返すのではなく、異なる問いへ答えるように整理します。

テストの範囲	この例で確かめる問い
単体	期間条件から対象の行を選ぶ処理が、境界の日付を含めて仕様どおりか
結合	画面から渡した期間条件が出力処理へ届き、ファイル取得へつながるか
システム	権限と利用条件を含め、合意した要件を全体として満たすか
受入	管理担当が業務で必要な列と対象データを取得し、目的の確認に使えるか

これはテスト設計の全体ではありません。文字の扱いやデータ量、取得に失敗する場合などは、実際の要件に応じて別途検討します。

単体テストが通っても、画面から違う条件が渡れば期待するファイルにならないかもしれません。全体が動いても、必要な列が要件に含まれていなければ、業務で使えない可能性があります。異なる水準を分けるのは、こうした確認対象を曖昧にしないためです。

対応を実務で使うには、図を保存するだけでなく、要求や設計の項目から確認結果へたどれる形を作ることを勧めます。例えば、要求に「R-出力-01」、確認項目に「T-出力-01」のような識別子を付け、参照先を残します。

記録は、少なくとも「根拠の要件・設計」「確認する条件」「期待結果」「実施結果」を区別します。資料が更新された場合に、どの確認を見直すべきか探すためです。

前のCSV例で対象期間の仕様が変わったなら、単体の境界条件だけでなく、画面の指定方法と業務確認にも影響がないかを見ます。すべてを無条件にやり直すか、何も見直さないかの二択にはしません。

この対応表だけで、テストの担当、完了条件、必要な環境、実施順序まで確定するわけではありません。担当者と利用部門の役割、残った不具合の扱いも、プロジェクトで決める必要があります。

また、V字の図を使ったから変更が起きないわけでも、品質が保証されるわけでもありません。反復して小さく作る開発でも、「どの要求を何で確かめたか」という対応は整理できます。採用する開発手法に合わせて、資料や記録の単位を決めてください。

まず一つの機能を選び、要件からテスト結果まで追えるか確認してみましょう。利用部門の確認は受入テストの準備、実装変更の確認はコードレビューの観点も参考になります。開発体制については、テクノヴァースのSES事業をご覧ください。