このフェーズの座組み

テストフェーズの座組みと成果物

図1: テストフェーズの役割・成果物・タスク

テストフェーズ — 座組み

フル稼働QAアプリ（FE）アプリ（BE）セキュリティ
部分参加PMインフラDBA

テスト種別と担当・成果物

テスト種別主担当成果物ポイント
単体テストアプリFE/BEテスト結果エビデンス、カバレッジレポートカバレッジ基準は事前合意（80%以上等）すること。カバレッジが高くてもテストの質が低い場合がある。
結合テスト横断QA ＋ アプリ結合テスト仕様書・実施記録、障害票API境界・外部システム連携・非同期処理の検証が主眼。障害票の管理ツールを統一する。
システムテスト横断QA主導システムテスト仕様書・実施記録、不具合管理票要件定義書との照合が主眼。すべての機能要件が実装されているかを確認する。
性能・負荷テストインフラ＋DBA＋QA負荷テスト計画書・実施記録、ボトルネック分析レポート本番相当のデータ量・同時接続数で実施。3者が担当ごとのボトルネックを分析する。
セキュリティテスト横断セキュリティ脆弱性診断報告書、対応記録、修正確認記録OWASPトップ10を最低限カバー。発見した脆弱性の修正確認（再診断）まで含める。
UAT管理PM ＋ ビジネス側UAT実施記録、受入合意書ビジネス側の署名入り受入合意書なしでリリース判定に進まない。これがリリース判定の根拠になる。

性能テストの3者協働

性能・負荷テストはインフラ・DBA・QAの3者が担当を分けて協働する。

担当分析対象
インフラインフラCPUボトルネック・メモリ不足・ネットワーク帯域・スケールアウトの効果
データDBAスロークエリ・ロック競合・インデックス使用率・バッファヒット率
横断QAテストシナリオの妥当性・実際のユーザー行動パターンとの乖離

UATはPM主導で進める

💡 UATをQAだけに任せてはいけない

UATはビジネス側が「このシステムを受け入れる」と判断するプロセスだ。技術的なテストではなくビジネス要件の確認なので、PMが主導してビジネス側を巻き込む。受入合意書に署名をもらうことが、リリース判定の正式な根拠になる。

UATでよく発生する問題は「ビジネス側が参加しない・参加できない」ケースだ。「開発チームがテストしてOKだったなら大丈夫」と委ねられてしまうと、ユーザー視点での確認が抜け落ちる。UAT の日程はプロジェクト開始時に確保しておき、ビジネス担当者のカレンダーを押さえることが重要だ。

UATで確認すること技術的テストとの違い
業務フローが実際に回るか単体・結合テストでは「機能が動くか」を確認するが、UATでは「業務として使えるか」を確認する
画面の操作感・UIが業務に合っているか仕様書通りの実装であっても「現場では使いにくい」と判断されることがある
業務例外（エラーケース）への対処が適切か正常系だけでなく、業務で実際に発生しうる異常系を現場目線で確認する

テストフェーズを円滑に進めるためのポイント

テストフェーズは開発が「終わってから始まる」と思われがちだが、実際には開発と並行して準備を進めないと後半のスケジュールが大きく圧迫される。

ポイント具体的な対策
テスト仕様書を早めに作る要件定義が固まった時点でQAがテスト仕様書の作成を開始する。開発完了を待ってから作り始めると、テスト期間が短くなる。
障害票の管理ツールを統一するGitHub Issues / Jira / Redmine など何を使うか最初に決める。ツールがバラバラだと障害の追跡が困難になる。
テスト環境を本番に近づける特に性能・負荷テストでは本番相当のデータ量・サーバースペックが必要。開発環境との差が大きいと結果の信頼性が下がる。
バグの優先度分類を決めるCritical（リリースブロッカー）/ Major / Minor の基準を全員で合意しておく。基準が曖昧だと「これはリリースに影響するか」の議論で時間を消費する。

✅ 次のPARTへ

→ PART 10 — リリース／移行フェーズの成果物と役割へ