系统开发
要求分析
もっとも上流の開発工程となる「要求定義」では、ユーザーテストとも呼ばれる「受け入れテスト」の設計が実施されます。 要求定義とは、開発するシステムに求める依頼側の要求・機能をまとめたもの。 どんな課題を抱えて、どうすれば解決できるのかを言語化していきます。
・現状の課題（何に困っているのか） ・理想の状態（どうなれば解決するのか） ・システム機能（どんな機能があれば良いのか）
例えば「○名が同時にアクセスして××を1秒以内に並列処理できるシステム」「○○ボタンをクリックすると、××と△△を処理できる機能」といった概要を決定します。
要求定義に対応する受け入れテストとは、最終的に納品されるシステム（プログラム）が、要求定義を満たしているのか？依頼側のユーザーが確認するためのテストです。
開発工程としての要求定義の粒度は「ユーザーがシステムで実現したいこと」なので、受け入れテストは「機能テスト」「ユーザビリティテスト」が中心となります。このフェーズを担当するのはPM（プロジェクトマネージャー）ですが、依頼側の積極的な関与も必須です。
| 開発工程 | テスト | 主なテスト項目 | 内容 | 確認者 |
|---|---|---|---|---|
| 要求定義 | 受け入れテスト | 機能テスト | 実稼働時の状況を想定しながらシステム全体の動作を検証する | PM 依頼者 |
| ユーザビリティテスト | 実際の業務、それを想定したシナリオを用意してシステムを稼働させ、使用感・操作感などをチェック・検証 |
要件定義
「要件定義」工程では、システムテストとも呼ばれる「総合テスト」の設計が実施されます。
要件定義とは、クライアントのニーズである要求定義を、開発するシステムでどのように実現していくか？必要な要件をまとめたもの。 下記のような内容を決めます。
・開発目的 ・予算 ・必要な機能 ・スケジュール（納期） ・必要な人員（工数）
要件定義に対応する総合テストとは、納品される前のシステム（プログラム）が、要件定義を満たしているのか？開発側が確認する最終テストです。
要件定義の粒度は「システムに実装された機能・非機能（性能などの機能以外の要件）要件が満たされているか」。
総合テストでは「確認テスト」「評価テスト」「負荷テスト」が中心となります。要求定義同様、PMおよび依頼側の関与が重要になります。
| 開発工程 | テスト | 主なテスト項目 | 内容 | 確認者 |
|---|---|---|---|---|
| 要件定義 | 総合テスト | 確認テスト | プログラムや、プログラム同士の連携に不具合がないか？正しい挙動を示しているか？検証 | PM 依頼者 |
| 評価テスト | 使い勝手、セキュリティ、障害時の耐性など、システムの性能を評価して検証 | |||
| 負荷テスト | システムに大きな負荷をかけて稼働させ、耐久性やパフォーマンスに問題が生じないかを確認・検証 |
基本設計
「基本設計」工程では「結合テスト」の設計が実施されます。
基本設計とは、要件定義をもとに、UI（ユーザーインターフェース）などの外側から見たシステムを設計するフェーズで。基本設計で行う作業内容は以下の通りです。
・機能の洗い出し ・扱うデータを整理 ・画面のレイアウトを決める ・必要となるデータを明確化
基本設計に対応する結合テストとは、機能ごとに分割してプログラミングされたモジュール（部品を集めて機能を持たせたもの）がサブシステムとしてキチンと連携できるか？モジュールを結合させて確認するテストです。
基本設計の粒度は「基本設計書・仕様書通りにプログラムが動作するか」です。
結合テストでは「ブラックボックステスト」「インターフェーステスト」「トップダウン・ボトムアップテスト」が中心となります。基本設計を担当するのはSE（システムエンジニア）、PMですが、依頼側が携わる最後のチャンスでもあります。
| 開発工程 | テスト | 主なテスト項目 | 内容 | 確認者 |
|---|---|---|---|---|
| 基本設計 | 結合テスト | ブラックボックステスト | 結合されたサブシステムにデータを入力し、正しい出力データが返ってくるかを検証 | SE PM 依頼者 |
| インターフェーステスト | 機能間やモジュール間でデータが正しく引き渡されるか検証 | |||
| トップダウン・ボトムアップテスト | サブシステムの上位、もしくは下位モジュールから順番に検証 |
詳細設計
「詳細設計」工程では「単体テスト」の設計が実施されます。
詳細設計とは、基本設計をもとに、プログラマーにわかる形でプログラミングの指示書・設計書を作成するフェーズであり、成果物は詳細設計書。
単体テストとは、プログラマーが開発・実装したモジュール単体が正常に動作するか確認するテストです。
詳細設計の粒度は「詳細設計書・仕様書通りにプログラムが動作するか」です。
単体テストでは、プログラムの処理を検証する「ホワイトボックステスト」が中心となります。詳細設計を担当するのはSEであり、依頼側が携わることはほとんどありません。
| 開発工程 | テスト | 主なテスト項目 | 内容 | 確認者 |
|---|---|---|---|---|
| 詳細設計 | 単体テスト | ホワイトボックステスト | 制作されたプログラムが設計通りの処理を実行できるか？網羅的に検証 | SE |
アジャイル型開発にでもV字モデルを採用できる
アジャイル型開発とは、おおまかに策定されたシステム要件を細かい機能に分割し、優先度の高い順に「計画」>「設計」>「実装」>「テスト」>「リリース」を1つのサイクルとした「イテレーション（反復）」を繰り返し、システムの完成を目指す開発モデルのこと。
アジャイル型にV字モデルを採用する際に必須となるのが、ユーザーと開発チーム、あるいはプロダクトオーナー（ウォーターフォール型でいうPM）との密接なコミュニケーションです。
アジャイル型でV字モデルを機能させようとしても、実態としてユーザー側の代表が常に参加できない、間に第三者が入ってしまうことが起きがち。イテレーション間が1〜3週間程度と短く、完成までが長期にわたりがちなことも課題のひとつとなるでしょう。
アジャイル型システム開発にV字モデルを採用する場合は、こうした品質管理上の問題を踏まえたうえで、関係者がしっかりプロジェクトにコミットできるのか、実現可能性も検討することが重要になります。