UATのテストケースを英語で書こうとして、何をどの列に書けばいいか迷うエンジニアは多い。グローバルチームでは「どのケースを誰がいつテストして、結果がどうだったか」を英語で一元管理することが求められる。
この記事では、ITプロジェクトで実際に使える英語UATテストケース管理表の書き方を解説する。フレーズ20選・日英Excelテンプレートもセットで用意した。コピペしてすぐに使える。
テストケースを英語で整備すると、バグの証跡が残り、サインオフの説得力が増す。さっそく構成と書き方を確認しよう。
英語UATテストケース管理表とは
UATテストケース管理表（UAT Test Case Management Sheet）とは、受け入れテストで実施するすべてのテストケースを一覧化した文書だ。テストの実施状況・結果・不具合を一か所で管理し、サインオフの判断材料にする。
英語では “UAT Test Case Sheet” “Test Case Log” “Acceptance Test Tracker” とも呼ばれる。
テストケース管理表が必要な理由
UATは「動いた・動かなかった」の口頭確認で済ませがちだ。しかし、証跡がないと「どのケースをテストしたか」「どのバグがクローズ済みか」があとから追えなくなる。
特にグローバルチームでは、テスト担当者が複数拠点にいる。誰が何をテストして、結果がどうだったかを英語で記録することで、サインオフの根拠が明確になる。
テスト計画書との違い
テスト計画書（Test Plan）はテストの方針・範囲・スケジュールを定義する文書だ。一方、テストケース管理表は実際のテスト項目・実行結果・不具合を記録するオペレーション文書になる。計画書と管理表はセットで使う。
テスト計画書の書き方は、【テンプレあり】英語テスト計画書の書き方｜ITプロジェクトで使える日英フォーマット付きも参考にしてほしい。
テストケースの5つの必須列
UATテストケース管理表には、最低限5つの列が必要だ。
1. テストケースID（Test Case ID）
“TC-001” “UAT-001” のように連番で管理する。バグ報告やミーティングで「TC-012の結果は？」と参照できるため、IDは必須だ。
2. テスト対象機能（Feature / Module）
どの機能・画面・モジュールをテストするかを記載する。“Login”, “Order Creation”, “Invoice Export” のように、機能単位で分類すると管理しやすい。
3. テスト手順と期待結果（Test Steps / Expected Result）
テスト手順を番号付きで記載し、「このステップを実行したらこうなるべき」という期待結果を明記する。期待結果が曖昧だと「合格か不合格か」の判断が人によって変わる。
4. 実際の結果（Actual Result）
テストを実行して実際に起きたことを記録する。期待結果と一致すれば “As expected”、不一致なら具体的な症状を記載する。
5. ステータス（Status）
“Pass” “Fail” “Blocked” “Not Tested” の4択が基本だ。Blocked（ブロック）は、前提条件が整っていないため実行できない状態を指す。
英語UATテストケースで使えるフレーズ20選
3つのカテゴリに分けてフレーズを紹介する。
テストケース記述フレーズ
| 日本語 | 英語フレーズ |
|---|---|
| 〇〇画面にログインする | Navigate to the [screen name] and log in |
| 〇〇ボタンをクリックする | Click the [button name] button |
| 〇〇フィールドに〇〇を入力する | Enter [value] in the [field name] field |
| 〇〇が正しく表示されること | [Element] is displayed correctly |
| 〇〇エラーメッセージが表示されること | An error message “[message]” is displayed |
| 〇〇ページにリダイレクトされること | The user is redirected to the [page name] page |
| データが正しく保存されること | The data is saved correctly in the database |
ステータス・結果フレーズ
| 日本語 | 英語フレーズ |
|---|---|
| テスト合格 | ✅ Pass |
| テスト不合格 | ❌ Fail |
| 実行ブロック（前提条件未整備） | ⚠️ Blocked |
| 未実施 | ⬜ Not Tested |
| 期待どおりの結果 | Actual result matches expected result |
| 期待と異なる結果 | Actual result does not match expected result |
| 再テスト待ち | Pending retest after fix |
バグ報告・エスカレーションフレーズ
| 日本語 | 英語フレーズ |
|---|---|
| バグとして起票しました | A defect has been logged as [BUG-ID] |
| 優先度Highのバグです | This is a High-priority defect — immediate attention required |
| 再現手順は〇〇です | Steps to reproduce: [step 1] → [step 2] → [step 3] |
| 修正後に再テストが必要です | Retest required after the fix is deployed |
| このケースはブロックされています | This test case is blocked pending [dependency] |
| 本番リリース前に解決が必要です | This must be resolved before the production release |
UATサインオフのフレーズは、【例文あり】エンジニアの英語UAT術｜テスト計画・バグ報告・サインオフフレーズ30選も参考にしてほしい。
テンプレートをダウンロード（Excel）
以下のExcelファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。ステータス列にはドロップダウンメニューが設定済みで、サインオフ記録シートも付属している。
空白テンプレート（書き込み用）
📥 日本語テンプレートをダウンロード（Excel）
📥 Download English Template (Excel)
完成版サンプル（記入例）
受注管理システム刷新プロジェクトの記入例だ。Pass/Fail/Blockedの色分け・バグID紐づけ・サインオフ記録の使い方がひと目でわかる。
📥 日本語サンプルをダウンロード（Excel）
📥 Download English Sample (Excel)
日本語版テンプレート（コピペOK）
以下のテンプレートを参考にして、プロジェクトに合わせて使ってほしい。Excelファイルはダウンロードして項目を自由に追加・削除できる。
基本情報
| 項目 | 内容 |
|---|---|
| プロジェクト名 | |
| UATフェーズ | UAT Phase 1 / Phase 2 |
| テスト期間 | 20XX年〇月〇日〜20XX年〇月〇日 |
| テスト責任者 | |
| 最終更新日 |
テストケース一覧
| テストケースID | 機能 | テスト概要 | テスト手順 | 期待結果 | 実際の結果 | ステータス | 担当者 | 実施日 | バグID | 備考 |
|---|---|---|---|---|---|---|---|---|---|---|
| TC-001 | ログイン | 正常ログイン | 1. ログイン画面を開く 2. 有効なID/パスを入力 3. ログインをクリック | ホーム画面にリダイレクトされる | ✅ Pass / ❌ Fail / ⚠️ Blocked / ⬜ 未実施 | |||||
| TC-002 | ログイン | 無効パスワードでのログイン | 1. ログイン画面を開く 2. 無効なパスを入力 3. ログインをクリック | エラーメッセージが表示される | ||||||
| TC-003 | 受注登録 | 新規受注の作成 | 1. 受注登録画面へ遷移 2. 必須項目を入力 3. 保存をクリック | 受注が保存され一覧に表示される |
サインオフ記録
| 役割 | 氏名 | 判断 | 日時 | コメント |
|---|---|---|---|---|
| UAT責任者 | 承認 / 差し戻し | |||
| 業務オーナー | 承認 / 差し戻し | |||
| プロジェクトマネージャー | 承認 / 差し戻し |
英語版テンプレート（コピペOK）
Basic Information
| Item | Details |
|---|---|
| Project Name | |
| UAT Phase | UAT Phase 1 / Phase 2 |
| Test Period | [Start Date] – [End Date] |
| Test Owner | |
| Last Updated |
Test Case Log
| Test Case ID | Feature | Test Summary | Test Steps | Expected Result | Actual Result | Status | Tester | Test Date | Bug ID | Notes |
|---|---|---|---|---|---|---|---|---|---|---|
| TC-001 | Login | Successful login with valid credentials | 1. Open login page 2. Enter valid ID and password 3. Click Login | User is redirected to the home screen | ✅ Pass / ❌ Fail / ⚠️ Blocked / ⬜ Not Tested | |||||
| TC-002 | Login | Login attempt with invalid password | 1. Open login page 2. Enter invalid password 3. Click Login | Error message is displayed | ||||||
| TC-003 | Order Entry | Create a new order | 1. Navigate to order entry screen 2. Enter required fields 3. Click Save | Order is saved and appears in the order list |
Sign-off Record
| Role | Name | Decision | Date & Time | Comments |
|---|---|---|---|---|
| UAT Owner | Approved / Rejected | |||
| Business Owner | Approved / Rejected | |||
| Project Manager | Approved / Rejected |
テストケース管理表を英語で使う3つのポイント
期待結果は「〇〇であること」と明確に書く
“Works correctly” のような曖昧な期待結果は禁物だ。“The user is redirected to the home screen” “An error message ‘Invalid credentials’ is displayed” のように、具体的な状態・表示・動作を明記する。曖昧な記載は「合格基準が人によって違う」という問題を生む。
バグIDを必ずテストケースに紐づける
Failになったテストケースは、バグ管理ツール（Jira・Redmineなど）のチケット番号をバグID列に記載する。テストケースとバグが紐づくことで、「どのバグが修正されてどのテストが再合格したか」のトレーサビリティが確保できる。
Blockedは原因と解除条件を備考欄に書く
“Blocked” のまま放置すると、何が原因でいつ再開できるのかが不明になる。“Blocked: Waiting for test data setup by DBA — expected by 2026/05/19” のように、ブロック原因と解除見込み日を備考欄に必ず記載する。
QA全体の議論フレーズは、【例文あり】エンジニアの英語テスト・QA議論術｜テスト計画・バグトリアージフレーズ30選も参考にしてほしい。
UATの結果をまとめるテスト結果報告書のテンプレートは、【テンプレあり】英語テスト結果報告書の書き方｜ITプロジェクトで使える日英フォーマット付きも参考にしてほしい。
まとめ：UATテストケース管理表で合否の根拠とサインオフの説得力を確保する
英語UATテストケース管理表の要点は3つだ。
- 5列で網羅：テストケースID・機能・手順と期待結果・実際の結果・ステータス
- 期待結果を具体的に書く：曖昧な表現は合格基準のブレを生む
- バグIDとBlockedの理由を紐づける：証跡とトレーサビリティがサインオフの説得力を高める
テストケースを英語で整備すると、「どのケースを誰がいつ確認したか」が一目でわかる。Excelテンプレートを活用して、次のUATからすぐに使ってみてほしい。
コメント