テストには４種類（テスト名については差異があるかもしれませんが、役割・工程に大きな違いはないと思います）あり、細部から徐々に規模を大きくしていきます。テストの流れは状況にもよりますが、単体テストからシステムテストまでを繰り返し、最後に運用テストで閉めることになります。
ユーザーの役割は、要件定義書に沿って求めた機能が正しく実装されているかを確認すること！「仕掛けを知ろうとせずに動作を知ること」に注力しましょう。
単体テスト（モジュール単位のテスト）
- 主担当者
- プログラマー
- テストの目的
- モジュール単位にプログラムコードの検証を行うことです。モジュールとはシステムを構成する部品です（例えば日付から曜日を求める等）。システムは小さなモジュールの結合で成り立っています。単体でテストすることで他モジュールの影響を排除し、シンプルに欲する機能が全て満たされているか検査します。
- 自転車作りに例えれば……
- タイヤを分解すると、車輪、内ゴム・外ゴム、スポーク等に分解されますが、求める口径によってその一つ一つが異なります。単体テストとは、スポークの長さや強度が設計通りに作られているかを検証することです。
結合テスト（内部設計のテスト）
- 主担当者
- ＳＥ（システムエンジニア）
- テストの目的
- 複数のモジュールを繋ぎ合わせることで、１つの機能（ユニット）が生まれます。上記単体テストで検証されたモジュール群が全て正しく結合されているかチェックします。
- 自転車作りに例えれば……
- 別々に発注していた車輪やスポークを組み合わせ、タイヤが設計通りに組みあがるか検証することです。
システムテスト（外部設計のテスト）
- 主担当者
- ユーザー/ＳＥ
- テストの目的
- 上記結合テストで検証されたユニット群をつなぎ合せ、要件定義で求められた機能が全て満たされているかチェック。
- 自転車作りに例えれば……
- でき上がってきた車体・タイヤ・ブレーキ等を組み合わせ、自動車としての主機能はもちろん、自分が求めイメージ通りにでき上がっているか隅々まで検証します。
運用テスト（ほぼ本番環境でのテスト）
- 主担当者
- ユーザー
- テストの目的
- 本番と同じ環境（マシン・データ件数等）・運用手順で実際にチェック。データ件数やネットワーク環境、同時利用者数等を本番に近づけてレスポンスの検証も忘れずに！
- 自転車作りに例えれば……
- 外に出て試乗し、乗り心地や耐久性を確認します。実際に使う環境下での完成度をチェックします。