UATや結合テストが終わったあとに「テスト結果報告書を英語で書いて」と言われ、何をどう構成すればいいか迷うエンジニアは多い。グローバルチームでは合否サマリー・欠陥一覧・未解決の問題・サインオフをまとめた報告書が、フェーズ移行や本番リリースの判断材料となる。
この記事では、ITプロジェクトで実際に使える英語テスト結果報告書の書き方を解説する。フレーズ20選・日英Wordテンプレートもセットで用意した。コピペしてすぐに使える。
テスト結果報告書を英語で整備すると、品質の透明性が上がり、ステークホルダーの承認をスムーズに得られる。さっそく構成と書き方を確認しよう。
英語テスト結果報告書とは
テスト結果報告書（Test Results Report）とは、テストフェーズの実施結果を一か所にまとめた文書だ。計画テストケース数・合否・欠陥（バグ）・未解決の問題・サインオフを整理し、プロジェクトマネージャー・クライアント・ステアリングコミッティが次フェーズへ移行してよいか判断するために使う。
英語では “Test Results Report” のほか “Test Completion Report” “Quality Assurance Report” とも呼ばれる。
テスト結果報告書が必要な理由
テスト結果報告書がないと「テストは合格したのか」「未解決のバグはいくつあるか」をステークホルダーが把握できない。特にUAT（ユーザー受け入れテスト）フェーズでは、クライアントのサインオフを文書で取得することが本番リリースの前提条件となる。
また、テスト結果を定量的に示すことで「合格率〇%・重大バグ0件」という根拠が明確になり、リリース判断の信頼性が高まる。
テスト計画書との違い
テスト計画書（Test Plan）はテスト開始前に「何を・どのようにテストするか」を定義する文書だ。一方、テスト結果報告書は「実際にどうだったか」を記録するテストフェーズの締め文書として機能する。テスト計画書と結果報告書はセットで管理する。
テスト計画書の書き方は、【テンプレあり】英語テスト計画書の書き方｜ITプロジェクトで使える日英フォーマット付きも参考にしてほしい。
テスト結果報告書の6つの必須セクション
英語テスト結果報告書は6つのセクションで構成するのが基本だ。
1. テスト概要（Test Summary）
プロジェクト名・テストフェーズ・テスト期間・テスト責任者を記載するセクションだ。読み手が「どのフェーズの・いつの結果か」を一目で把握できるよう、最初に明記する。
2. テスト範囲（Test Scope）
テスト対象システム・モジュール・スコープ外の項目を記載するセクションだ。「何をテストしたか・しなかったか」を明確にすることで、報告書の適用範囲を読み手に正確に伝える。
3. テスト結果サマリー（Test Results Summary）
計画テストケース数・実施数・合格（Pass）・不合格（Fail）・未実施（Not Executed）・合格率を数字で示すセクションだ。一覧表にまとめることで、テスト品質を定量的に伝えられる。
4. 欠陥・バグ一覧（Defect Summary）
発見されたバグを重要度・症状・ステータス・担当者・修正予定日で一覧化するセクションだ。”Critical（致命的）・High（高）・Medium（中）・Low（低）” の重要度分類を使うと、優先度がひと目でわかる。
5. 未解決の問題（Outstanding Issues）
テスト終了時点で未対応の問題を記載するセクションだ。「問題の内容・対応方針・対応期限」をセットで記載することで、次フェーズへの持ち越しリスクを明示できる。
6. サインオフ・承認（Sign-off / Approval）
テスト完了をテスト責任者・PM・クライアント代表が署名で承認するセクションだ。サインオフなしで次フェーズへ進むと、後から「品質が不十分だった」という議論が起きやすい。
英語テスト結果報告書で使えるフレーズ20選
3つのカテゴリに分けてフレーズを紹介する。
テスト結果・合否フレーズ
| 日本語 | 英語フレーズ |
|---|---|
| テストフェーズ〇〇が完了しました | [Test phase] has been completed as of 2026/05/19 |
| 計画〇〇件中〇〇件を実施し、合格率は〇〇%です | Of [X] planned test cases, [Y] were executed with a pass rate of [Z]% |
| 全テストケースが合格しました | All [X] test cases have passed |
| 重大な欠陥は検出されませんでした | No critical defects were identified during testing |
| 〇〇件の欠陥が検出されました | [X] defects were identified, of which [Y] are classified as [severity] |
| 未実施のテストケースが〇〇件あります | [X] test cases were not executed due to [reason] |
| テスト範囲は〇〇を対象としています | The scope of this test covers [systems/modules] |
欠陥・バグ報告フレーズ
| 日本語 | 英語フレーズ |
|---|---|
| 〇〇機能に致命的な欠陥が検出されました | A critical defect was identified in [feature] |
| このバグは〇〇条件下で再現します | This defect is reproducible when [condition] |
| 〇〇件の高優先度バグが未修正です | [X] high-severity defects remain open |
| 本バグは次リリースで対応予定です | This defect is scheduled to be fixed in [release/version] |
| 回避策として〇〇を実施することで影響を最小化できます | As a workaround, [action] can minimize the impact |
| 修正済みバグの再テストが完了しました | Retesting of resolved defects has been completed |
サインオフ・承認依頼フレーズ
| 日本語 | 英語フレーズ |
|---|---|
| テスト結果に基づき、次フェーズへの移行を推奨します | Based on the test results, we recommend proceeding to the next phase |
| 本報告書へのサインオフをお願いします | We kindly request your sign-off on this test results report |
| 〇月〇日までに承認をいただきたいです | We respectfully request approval by 2026/05/19 to maintain the project schedule |
| 未解決の問題は本番リリース前に解消する予定です | Outstanding issues will be resolved prior to the production release |
| 残存リスクを承認のうえ、次フェーズへ進むことを確認します | We acknowledge the residual risk and confirm readiness to proceed |
| ご不明な点がある場合はお知らせください | Please let us know if you have any questions or concerns |
| 本報告書はプロジェクト記録として保管してください | This report should be retained as part of the project records |
UATのテストフレーズは、【例文あり】エンジニアの英語UAT術｜テスト計画・バグ報告・サインオフフレーズ30選も参考にしてほしい。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
空白テンプレート（記入なし）
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
記入済みサンプル（受注管理システム刷新）
📥 記入済みサンプルをダウンロード（日本語・Word）
📥 Download Completed Sample (English, Word)
日本語版テンプレート（コピペOK）
以下のテンプレートを参考にして、プロジェクトに合わせて使ってほしい。
テスト概要
| 項目 | 内容 |
|---|---|
| プロジェクト名 | |
| テストフェーズ | 結合テスト / UAT / 回帰テスト |
| テスト期間 | 20XX年〇月〇日 〜 〇月〇日 |
| テスト責任者 | |
| 作成日 |
テスト範囲
- 対象システム・モジュール：〇〇
- テスト対象外：〇〇
テスト結果サマリー
| 項目 | 件数 |
|---|---|
| 計画テストケース数 | |
| 実施テストケース数 | |
| 合格（Pass） | |
| 不合格（Fail） | |
| 未実施（Not Executed） | |
| 合格率 | 〇% |
欠陥・バグ一覧
| バグID | 重要度 | 概要 | ステータス | 修正担当者 | 修正予定日 |
|---|---|---|---|---|---|
| 致命的/高/中/低 | 未対応/対応中/修正済 |
未解決の問題
| 問題ID | 内容 | 対応方針 | 対応期限 |
|---|---|---|---|
サインオフ・承認
| 役割 | 氏名 | サイン | 日付 |
|---|---|---|---|
| テスト責任者 | |||
| プロジェクトマネージャー | |||
| クライアント代表 |
英語版テンプレート（コピペOK）
Test Summary
| Item | Details |
|---|---|
| Project Name | |
| Test Phase | System Testing / UAT / Regression Testing |
| Test Period | [Start Date] – [End Date] |
| Test Lead | |
| Date Prepared |
Test Scope
- In Scope: [Systems / Modules covered]
- Out of Scope: [Exclusions]
Test Results Summary
| Item | Count |
|---|---|
| Total Test Cases Planned | |
| Total Test Cases Executed | |
| Pass | |
| Fail | |
| Not Executed | |
| Pass Rate | [X]% |
Defect Summary
| Bug ID | Severity | Description | Status | Assignee | Target Fix Date |
|---|---|---|---|---|---|
| Critical/High/Medium/Low | Open/In Progress/Fixed |
Outstanding Issues
| Issue ID | Description | Resolution Plan | Target Date |
|---|---|---|---|
Sign-off / Approval
| Role | Name | Signature | Date |
|---|---|---|---|
| Test Lead | |||
| Project Manager | |||
| Client Representative |
テスト結果報告書を英語で書く3つのポイント
テスト結果は必ず数字で示す
「テストはほぼ完了しました」という曖昧な表現では、ステークホルダーが品質を判断できない。「200件中198件合格・合格率99%・Critical欠陥0件」のように、計画数・実施数・合格率・重要度別欠陥数を数字で示す。数字があることで、リリース判断の根拠が明確になる。
未解決バグには必ず対応方針を添える
残存バグを “Open” として並べるだけでは、ステークホルダーは「この状態でリリースして大丈夫か」と不安になる。「対応方針（回避策 or 次バージョン対応）・対応期限」をセットで記載することで、残存リスクをコントロールしている姿勢を示せる。
サインオフ欄を必ず設ける
テスト結果報告書にサインオフ欄がないと、「誰がいつ承認したか」の記録が残らない。後からクライアントに「品質不足だった」と言われたとき、サインオフ記録が唯一の証拠になる。テスト責任者・PM・クライアント代表の3者がサインする構成が標準だ。
UATテストケース管理表の書き方は、【テンプレあり】英語UATテストケース管理表の書き方｜ITプロジェクトで使える日英Excelフォーマット付きも参考にしてほしい。
まとめ：英語テスト結果報告書でテスト品質の透明性とリリース判断の根拠を高める
英語テスト結果報告書の要点は3つだ。
- 6セクションで網羅：テスト概要・テスト範囲・結果サマリー・欠陥一覧・未解決の問題・サインオフ
- テスト結果は数字で示す：合格率・重要度別欠陥数でステークホルダーが判断できる根拠を作る
- 未解決バグには対応方針と期限を添える：残存リスクのコントロールを明示する
テスト結果報告書をプロジェクト標準として整備することで、フェーズ移行・本番リリースのたびに「何を書けばいいか」で迷う時間がなくなる。Wordテンプレートを活用して、今すぐ自チームのフォーマットを作ってみてほしい。
コメント