🔥

総合テストの鉄壁チェックリスト20選

2025/11/04に公開

総合テスト（システムテスト）は、主に 「計画・準備」「環境構築」「実行」「完了」 のフェーズで進められます。

 1. 計画・準備フェーズ：完璧な結婚式の企画書づくり！

#
チェック項目
チェック対象外にできる条件

1

【計画書】 最新版の総合テスト計画書（テストの目的、範囲、開始/終了基準が書かれたもの）が承認され、関係者全員に共有されているかを確認してください。

「テスト戦略会議の議事録」 に、計画書の内容がすべて明記され、承認された記録があればOKです。

2

【要件網羅】 テストケースが、要件定義書に記載されている機能要件（〇〇ができる、という要求）をすべてカバーしているか、トレーサビリティマトリクスで確認してください。
非機能要件のみを対象とした特定フェーズのテスト（例：性能テスト）の場合は、この確認は不要です。

3

【非機能網羅】 テストケースが、非機能要件（性能、セキュリティ、操作性などの要求）を満たしているか、テスト仕様書と対照して確認してください。

「セキュリティテスト」 や**「性能テスト」** など、専門部署が担当し、独立した報告書がある場合は、その報告書をもって代えることができます。

4

【手順書の明確さ】 テスト手順書に、**「入力値」と「期待される出力/結果」**が具体的に明記され、「操作手順」が一連の流れで分かりやすく書かれているか確認してください。
手順が自動化ツール（例: Selenium）のスクリプトとして存在する場合は、スクリプトと結果の対応が取れていればOKです。

5

【データの準備】 テストで使う マスタデータや初期データ が、本番環境のデータを元に個人情報などを削除・加工した上で、すべて準備されているか確認してください。
結合テストで既にデータ準備が完了しており、総合テストで 「追加の特別なデータ」 が不要な場合は対象外です。

 2. 環境構築フェーズ：豪華な式場のセッティング！

#
チェック項目
チェック対象外にできる条件

6

【本番類似性】 テスト環境の OSバージョン、ミドルウェア（Web/DBサーバー）、ネットワーク構成 が、本番環境と 可能な限り一致 しているか、サーバー担当者に確認してください。

「本番環境移行前の検証環境」 として、一部の外部システムとの連携が未接続で良い場合は、その旨が計画書に明記されていればOKです。

7

【外部連携】 連携する外部システム（例：決済システム、メール送信API）との接続設定が完了し、疎通確認 が取れているか、専用のテストケースを実行して確認してください。

「バッチ処理などの特定機能のみのテスト」 で、外部連携が一切発生しない場合は対象外です。

8

【データの投入】 準備したテストデータ（マスタ、トランザクション）が、環境に正しく投入され、期待通りのデータ量になっているか、DBツールで件数などを確認してください。
**「性能テスト」**のように、データ投入方法が専門的なスクリプトで行われる場合は、そのスクリプト実行結果をもって代えることができます。

9

【アクセス権】 テストに参加する全メンバーのアカウントが作成され、**必要なアクセス権限（ロール）**が正しく付与されているか、ログインテストで確認してください。
特定のセキュリティテスト（例：権限昇格テスト）の場合、意図的に不適切な権限でテストを行う場合は対象外です。

10

【バージョン確認】 テスト対象のプログラムやドキュメントのバージョンが、テスト計画書に記載された**「ベースライン（テスト対象のバージョン）」**と一致しているか、ファイル名やコミットIDで確認してください。
CI/CDパイプラインで自動デプロイされた場合、デプロイログのバージョン情報をもって代えることができます。

 3. テスト実行フェーズ：誓いの言葉とトラブル対応！

#
チェック項目
チェック対象外にできる条件

11

【正常系テスト】 テスト手順書通りに操作し、期待通りの動作（画面遷移、計算結果、DB更新など）が得られたことをスクリーンショットやログで記録してください。
画面操作のない**「バッチ処理のテスト」の場合、「ログやDBの結果確認」**をもって代えることができます。

12

【異常系テスト】 無効な値の入力、未入力、権限のない操作などを行った際に、システムが適切なエラーメッセージを表示し、不正な処理が行われないことを確認してください。
テスト計画で異常系テストの範囲外と明記されている**「致命的なシステムエラー（例：電源断）」**に関する項目は対象外です。

13

【性能・負荷】 システムの応答時間が、非機能要件で定められた**基準（例：3秒以内）**を満たしているか、測定ツールのログを確認してください。
**「性能テスト」**が独立した専門チームによって実施され、専門の報告書がある場合は対象外です。

14

【セキュリティ】 SQLインジェクションやクロスサイトスクリプティングなどの基本的な脆弱性に対する対策が有効であるか、セキュリティ担当者の指示に従い確認してください。
**「セキュリティ専門企業による診断」**を別途実施し、その報告書で担保されている場合は対象外です。

15

【ユーザーインターフェース (UI)】 画面のデザイン、ボタンの配置、文字のフォントや色が、**デザイン仕様書（またはプロトタイプ）**通りになっているか確認してください。
**「アクセシビリティテスト」**など、UI/UX専門のテストチームが独立して実施する場合は対象外です。

16

【操作マニュアルとの整合性】 操作マニュアルに書かれている手順や画面イメージが、実際のシステムの画面や操作と完全に一致しているかを確認してください。
**「マニュアルの作成」**がテスト完了後に予定されている場合は、この時点では対象外です。

17

【ログ出力】 重要な操作やエラー発生時に、監査目的で必要な情報（ユーザーID、日時、操作内容など）がログファイルに正しく出力されているかを確認してください。
**「ログ出力のテストケース」**が、機能テストの過程で完全にカバーされている場合は、独立したチェックは不要です。

18

【回帰テスト（リグレッション）】 既存の重要機能（過去に動いていた機能）が、今回の改修によって意図せず不具合を発生させていないか、自動/手動で再テストを実施し確認してください。
修正範囲が極めて限定的で、影響分析の結果、回帰テストが不要と判断された場合は対象外です。

19

【不具合の管理】 テスト中に発見された不具合が、不具合管理表（JiraやRedmineなど）にすべて記録され、再現手順、エビデンスが添付されているか確認してください。
**「開発者が即座に修正し、その場で再テストが完了した軽微な修正」**で、管理者が承認した場合は対象外です。

 4. テスト完了フェーズ：ハッピーエンドの報告書提出！

#
チェック項目
チェック対象外にできる条件

20

【終了基準の達成】 総合テスト計画書に定めた**「テスト終了基準」（例：重要度の高い不具合がゼロ、テストケースの実行率100%など）がすべて満たされている**かを確認してください。

「フェーズゲート会議の議事録」で、テスト完了基準の例外的な扱いが承認されている場合は、その承認内容に従います。

21

【完了報告書】 テストの結果（実行率、合格率、未解決の不具合、品質評価など）をまとめた**「テスト完了報告書」**が作成され、責任者のレビュー・承認を得ているか確認してください。
**「次フェーズへの移行会議の議事録」**に、完了報告書に相当する主要な結果がすべて記載され、承認された場合は対象外です。

22

【環境のクリーンアップ】 テスト環境として準備したサーバーやデータが、次の作業（例：受け入れテスト、本番移行）のために必要な状態で維持されるか、またはクリーンアップされたかを確認してください。
**「受け入れテスト（UAT）へ環境をそのまま引き継ぐ」**ことが計画書に明記されている場合は、クリーンアップは不要です。

 📚信頼できる一次ソース私がこれらのチェック項目を作成するにあたり、システムテストの一般的な流れや重要視される観点を参考にしました。特に、**「テスト計画」「環境構築」「テスト実行」**というプロセスを理解するのに役立つ情報源です。
出典元: BizDev Tech - システム開発（総合テスト）とは？目的や流れ注意点も解説

出典元: SHIFT - システムテスト（総合テスト）とは？その目的・観点・種類、実務で使える手順について解説
これらのプロセス（計画、準備、実行、完了）を具体的なチェック項目に落とし込み、新人さんでも「イエス/ノー」で判断できる形にしました。これで**「うっかりミス」**の予防はバッチリです！

#	チェック項目	チェック対象外にできる条件
1	【計画書】最新版の総合テスト計画書（テストの目的、範囲、開始/終了基準が書かれたもの）が承認され、関係者全員に共有されているかを確認してください。	「テスト戦略会議の議事録」に、計画書の内容がすべて明記され、承認された記録があればOKです。
2	【要件網羅】テストケースが、要件定義書に記載されている機能要件（〇〇ができる、という要求）をすべてカバーしているか、トレーサビリティマトリクスで確認してください。	非機能要件のみを対象とした特定フェーズのテスト（例：性能テスト）の場合は、この確認は不要です。
3	【非機能網羅】テストケースが、非機能要件（性能、セキュリティ、操作性などの要求）を満たしているか、テスト仕様書と対照して確認してください。	「セキュリティテスト」や「性能テスト」など、専門部署が担当し、独立した報告書がある場合は、その報告書をもって代えることができます。
4	【手順書の明確さ】テスト手順書に、「入力値」と「期待される出力/結果」が具体的に明記され、「操作手順」が一連の流れで分かりやすく書かれているか確認してください。	手順が自動化ツール（例: Selenium）のスクリプトとして存在する場合は、スクリプトと結果の対応が取れていればOKです。
5	【データの準備】テストで使うマスタデータや初期データが、本番環境のデータを元に個人情報などを削除・加工した上で、すべて準備されているか確認してください。	結合テストで既にデータ準備が完了しており、総合テストで「追加の特別なデータ」が不要な場合は対象外です。

#	チェック項目	チェック対象外にできる条件
6	【本番類似性】テスト環境の OSバージョン、ミドルウェア（Web/DBサーバー）、ネットワーク構成が、本番環境と可能な限り一致しているか、サーバー担当者に確認してください。	「本番環境移行前の検証環境」として、一部の外部システムとの連携が未接続で良い場合は、その旨が計画書に明記されていればOKです。
7	【外部連携】連携する外部システム（例：決済システム、メール送信API）との接続設定が完了し、疎通確認が取れているか、専用のテストケースを実行して確認してください。	「バッチ処理などの特定機能のみのテスト」で、外部連携が一切発生しない場合は対象外です。
8	【データの投入】準備したテストデータ（マスタ、トランザクション）が、環境に正しく投入され、期待通りのデータ量になっているか、DBツールで件数などを確認してください。	「性能テスト」のように、データ投入方法が専門的なスクリプトで行われる場合は、そのスクリプト実行結果をもって代えることができます。
9	【アクセス権】テストに参加する全メンバーのアカウントが作成され、必要なアクセス権限（ロール）が正しく付与されているか、ログインテストで確認してください。	特定のセキュリティテスト（例：権限昇格テスト）の場合、意図的に不適切な権限でテストを行う場合は対象外です。
10	【バージョン確認】テスト対象のプログラムやドキュメントのバージョンが、テスト計画書に記載された「ベースライン（テスト対象のバージョン）」と一致しているか、ファイル名やコミットIDで確認してください。	CI/CDパイプラインで自動デプロイされた場合、デプロイログのバージョン情報をもって代えることができます。

#	チェック項目	チェック対象外にできる条件
11	【正常系テスト】テスト手順書通りに操作し、期待通りの動作（画面遷移、計算結果、DB更新など）が得られたことをスクリーンショットやログで記録してください。	画面操作のない「バッチ処理のテスト」の場合、「ログやDBの結果確認」をもって代えることができます。
12	【異常系テスト】無効な値の入力、未入力、権限のない操作などを行った際に、システムが適切なエラーメッセージを表示し、不正な処理が行われないことを確認してください。	テスト計画で異常系テストの範囲外と明記されている「致命的なシステムエラー（例：電源断）」に関する項目は対象外です。
13	【性能・負荷】システムの応答時間が、非機能要件で定められた基準（例：3秒以内）を満たしているか、測定ツールのログを確認してください。	「性能テスト」が独立した専門チームによって実施され、専門の報告書がある場合は対象外です。
14	【セキュリティ】 SQLインジェクションやクロスサイトスクリプティングなどの基本的な脆弱性に対する対策が有効であるか、セキュリティ担当者の指示に従い確認してください。	「セキュリティ専門企業による診断」を別途実施し、その報告書で担保されている場合は対象外です。
15	【ユーザーインターフェース (UI)】画面のデザイン、ボタンの配置、文字のフォントや色が、デザイン仕様書（またはプロトタイプ）通りになっているか確認してください。	「アクセシビリティテスト」など、UI/UX専門のテストチームが独立して実施する場合は対象外です。
16	【操作マニュアルとの整合性】操作マニュアルに書かれている手順や画面イメージが、実際のシステムの画面や操作と完全に一致しているかを確認してください。	「マニュアルの作成」がテスト完了後に予定されている場合は、この時点では対象外です。
17	【ログ出力】重要な操作やエラー発生時に、監査目的で必要な情報（ユーザーID、日時、操作内容など）がログファイルに正しく出力されているかを確認してください。	「ログ出力のテストケース」が、機能テストの過程で完全にカバーされている場合は、独立したチェックは不要です。
18	【回帰テスト（リグレッション）】既存の重要機能（過去に動いていた機能）が、今回の改修によって意図せず不具合を発生させていないか、自動/手動で再テストを実施し確認してください。	修正範囲が極めて限定的で、影響分析の結果、回帰テストが不要と判断された場合は対象外です。
19	【不具合の管理】テスト中に発見された不具合が、不具合管理表（JiraやRedmineなど）にすべて記録され、再現手順、エビデンスが添付されているか確認してください。	「開発者が即座に修正し、その場で再テストが完了した軽微な修正」で、管理者が承認した場合は対象外です。

#	チェック項目	チェック対象外にできる条件
20	【終了基準の達成】総合テスト計画書に定めた「テスト終了基準」（例：重要度の高い不具合がゼロ、テストケースの実行率100%など）がすべて満たされているかを確認してください。	「フェーズゲート会議の議事録」で、テスト完了基準の例外的な扱いが承認されている場合は、その承認内容に従います。
21	【完了報告書】テストの結果（実行率、合格率、未解決の不具合、品質評価など）をまとめた「テスト完了報告書」が作成され、責任者のレビュー・承認を得ているか確認してください。	「次フェーズへの移行会議の議事録」に、完了報告書に相当する主要な結果がすべて記載され、承認された場合は対象外です。
22	【環境のクリーンアップ】テスト環境として準備したサーバーやデータが、次の作業（例：受け入れテスト、本番移行）のために必要な状態で維持されるか、またはクリーンアップされたかを確認してください。	「受け入れテスト（UAT）へ環境をそのまま引き継ぐ」ことが計画書に明記されている場合は、クリーンアップは不要です。

1. 計画・準備フェーズ：完璧な結婚式の企画書づくり！

2. 環境構築フェーズ：豪華な式場のセッティング！

3. テスト実行フェーズ：誓いの言葉とトラブル対応！

4. テスト完了フェーズ：ハッピーエンドの報告書提出！

📚信頼できる一次ソース

Discussion