SIT vs UAT: 違いは何か
ソフトウェアテストに携わっているなら、SIT（System Integration Testing）と UAT（User Acceptance Testing）という用語が同じ意味で使われたり、「テストフェーズ」としてひとくくりにされたりしているのを見たことがあるでしょう。しかし、これらはまったく異なる目的を果たし、異なる時期に行われ、異なる人々によって実行されます。
要約すると、SIT は「システム同士が連携して動作するか?」と問い、UAT は「これはユーザーのニーズを満たしているか?」と問います。
この記事では、SIT と UAT の違いを分解し、それぞれがいつ行われるかを説明し、両方を効果的に実行する方法を示します。
SIT（System Integration Testing）とは
System Integration Testing（SIT）は、個々のソフトウェアモジュールやシステムを結合し、グループとしてテストするテストフェーズです。その目的は、統合されたコンポーネント間の相互作用（API、データベース、サードパーティサービス、内部モジュール）における欠陥を明らかにすることです。
誰が行うか? QA エンジニア、統合テスター、開発者 いつ行うか? 単体テストの後、UAT の前 焦点: 技術的インターフェース、データフロー、API 契約
SIT がテストするもの:
- フロントエンドとバックエンド間の API 呼び出しが正しいデータを返す
- データベースの読み書き操作がサービス間で機能する
- サードパーティ統合（決済ゲートウェイ、メールサービス、アナリティクス）が正しく機能する
- システム間の認証・認可フロー
- モジュール間のデータ形式とペイロードの互換性
- 下流サービスが利用できない場合のエラーハンドリング
SIT の例:
E コマースのチェックアウトフローをテストする場合: フロントエンドが注文データをバックエンド API に送信し、バックエンドがデータベースに書き込み、決済ゲートウェイを呼び出し、配送サービスを起動します。SIT は、UI がまだ完成していなくても、これらすべてのシステムがデータを正しく交換することを検証します。UAT（User Acceptance Testing）とは
User Acceptance Testing（UAT）は、実際のエンドユーザーが、システムが自社のビジネス要件を満たし、現実のシナリオで動作することを検証する最終テストフェーズです。
誰が行うか? エンドユーザー、ビジネスステークホルダー、プロダクトオーナー いつ行うか? SIT の後、本番リリースの前 焦点: ビジネスワークフロー、ユーザーエクスペリエンス、要件の検証
UAT がテストするもの:
- ユーザーは典型的なビジネスワークフロー（登録、注文、支払いなど）を完了できるか?
- システムはビジネス要件が指定するように動作するか?
- エラーメッセージとフィードバックは非技術系ユーザーに明確か?
- システムは現実世界のデータ量と境界ケース（edge case）を処理するか?
- ユーザーエクスペリエンスは日常使用に受け入れられるか?
UAT の例:
同じ E コマースのチェックアウトフロー: 実際のユーザー（開発者ではない）が、商品の検索から確認メールの受信まで、購入プロセス全体を実行します。API レスポンスを確認しているのではなく、フローが意味をなすかどうか、ボタンが期待する場所にあるかどうか、確認メールが届くかどうかを確認しています。SIT vs UAT: 主な違い
| 観点 | SIT (System Integration Testing) | UAT (User Acceptance Testing) |
|---|---|---|
| 目的 | システムが連携して動作することを検証 | ビジネス要件を検証 |
| 実施者 | QA エンジニア、開発者 | エンドユーザー、ビジネスステークホルダー |
| 時期 | 単体テストの後、UAT の前 | 本番前の最後のフェーズ |
| 焦点 | 技術的インターフェース、データフロー | ビジネスワークフロー、ユーザーエクスペリエンス |
| テストデータ | ダミーデータ、合成データセット | 現実的で本番に近いデータ |
| 環境 | 統合・ステージング環境 | ステージングまたはプレプロダクション環境 |
| 成功基準 | すべての統合が成功し、重大なデータ問題がない | ビジネスステークホルダーがサインオフ |
| ドキュメント | 技術的テストケース、API 仕様 | ビジネスシナリオ、ユーザーストーリー |
| バグの例 | API が500を返す、データベース書き込み失敗、データ形式の不一致 | 誤ったボタンラベル、わかりにくいナビゲーション、確認メールが届かない |
SIT と UAT: どのように連携するか
SIT と UAT は代替手段ではありません。相互に構築し合う連続したフェーズです:
Unit Testing → SIT → UAT → Production Release
SIT は UAT 開始前に合格しなければなりません。 システムが正しく統合されていなければ、ユーザーにワークフローをテストさせても意味がありません。壊れた API があれば、UX がどれほど優れていても、ユーザーはチェックアウトを完了できません。
UAT は SIT が価値があったことを検証します。 すべてのシステムが完璧に統合されていても、ソフトウェアはビジネステストに失敗する可能性があります。UAT は「決済フローは技術的に正しいが、ユーザーがエラーメッセージを理解できない」のようなことを検出します。
SIT テストとは（詳細）
SIT テストには主に2つのアプローチがあります:
1. ビッグバン統合（Big Bang Integration）
すべてのモジュールを一度に統合し、まとめてテストします。セットアップは迅速ですが、欠陥を特定しにくいという欠点があります。2. インクリメンタル統合（Incremental Integration）
モジュールを1つずつ（または小さなグループごとに）統合してテストします。デバッグは容易ですが、時間がかかります。一般的な SIT テスト手法:
- トップダウン（top-down） — 上位レベルのモジュールを先にテストし、下位レベルのモジュールをスタブ化
- ボトムアップ（bottom-up） — 下位レベルのモジュールを先にテストし、上に向かって統合
- サンドイッチ（Sandwich） — トップダウンとボトムアップのアプローチを組み合わせる
UAT vs SIT: よくある誤解
「UAT は人が増えただけの SIT だ」
違います。SIT と UAT は根本的に異なる目標を持ちます。SIT は技術的な正しさをチェックし、UAT はビジネス価値をチェックします。一方を他方で置き換えることはできません。「SIT が合格すれば、UAT はおまけにすぎない」
これは危険です。技術的に正しいソフトウェアでも、ユーザーの期待やビジネス要件に合致しなければ、UAT に失敗する可能性があります。UAT を常に本物の検証フェーズとして実施してください。「開発者が UAT をできる」
開発者はシステムに近すぎます。彼らはシステムがどう動くべきかを知っているため、無意識に楽観的なパス（happy path）をたどります。実際のエンドユーザーは新しい視点をもたらし、開発者が考えもしない問題を見つけます。SIT と UAT のベストプラクティス
SIT の場合:
UAT の場合:
UAT 中の BugCapturer の活用法
UAT 中、テスター（技術者ではない）は問題を明確に報告する必要があります。バグレポートと視覚的フィードバックのための無料 Chrome 拡張機能である BugCapturer は、このために設計されています:
- スクリーンショットの注釈: ページ上に矢印、矩形、テキストを直接追加して、何が問題なのかを正確に示せます。別途画像エディタは不要です。
- 画面録画: バグを短い WebM 動画で録画し、トリミングしてキーフレームを抽出。断続的な問題のデモンストレーションに最適です。
- 技術メタデータの自動取得: URL、ブラウザ、OS、画面解像度、ビューポートが自動的に取得されます。テスターがこれらの詳細を手動で入力する必要はありません。
- 診断データ収集: コンソールエラーと失敗したネットワークリクエスト（HTTP ステータス ≥ 400）が視覚的証拠とともに取得されます。ネットワーク URL は、機密パラメータが自動的にマスキングされます。
- ワンクリックメール: すべてがバグレポートテンプレートに一致する構造化メールにまとめられ、開発者に送信する準備が整います。
- Excel/TSV エクスポート: チームレベルでの追跡のため、12列の構造化バグレポート行をワンクリックでクリップボードにコピー。
結果: UAT 参加者はバグ追跡ツールのトレーニングを一切必要としません。クリックして、注釈を付けて、送信するだけです。開発者は問題を再現して修正するために必要なすべてを手に入れます。