テストケースレビューで差し戻される理由！現役SEが実務で見ている確認ポイント

テストケースを作ったのに、レビューで何度も差し戻される。初心者SEにとって、かなりつらい場面だと思います。

自分では仕様書を読んでテストケースを作ったつもりでも、レビューでは「期待結果が曖昧」「条件が足りない」「何を確認したいのか分からない」と指摘されることがあります。

私自身、現場でテストケースを作る側、レビューする側の両方を経験してきました。その中で感じるのは、テストケースは数を増やすだけでは意味がないということです。

この記事では、テストケースレビューで差し戻されやすい理由と、現役SEとして私が実務で見ている確認ポイントを整理します。

テストケースは「実施できること」が重要

テストケースは、仕様を理解している人だけが分かるメモではありません。実施者が読んで、同じ手順で確認できる必要があります。

レビューで見られるのは、主に次の点です。

• どの仕様を確認するテストか分かるか
• 前提条件が明確か
• 操作手順が再現できるか
• 期待結果が具体的か
• 必要なテストデータが分かるか
• 合格・不合格を判断できるか

このどれかが曖昧だと、テストケースとして実施しにくくなります。

仕様書からテスト観点を出す考え方は「仕様書を読んでもテスト観点が出せないときの考え方」でも解説しています。

差し戻される理由1：期待結果が曖昧

テストケースで特に指摘されやすいのが、期待結果の曖昧さです。

たとえば、期待結果に次のように書かれているケースです。

• 正常に登録されること
• エラーになること
• 一覧に表示されること
• 正しく更新されること

一見問題なさそうですが、実務ではこれだけでは足りないことがあります。

「正常に登録」とは、どのテーブルにどの値が登録されることなのか。画面に完了メッセージが出ればよいのか。登録後の一覧表示や履歴も確認するのか。このあたりが曖昧だと、実施者によって確認範囲が変わります。

期待結果は、できるだけ判断できる形で書く必要があります。

• 登録完了メッセージが表示される
• 一覧画面に登録した名称が表示される
• DBのステータスが「有効」で登録される
• 必須項目未入力時に対象項目の下へエラーメッセージが表示される

このように書くと、確認する内容が明確になります。

差し戻される理由2：前提条件が足りない

テストケースには、手順だけでなく前提条件も必要です。

同じ操作でも、ユーザー権限、データ状態、ステータス、日付によって結果が変わることがあります。

たとえば、「注文をキャンセルする」というテストでも、次の前提によって期待結果は変わります。

• 注文ステータスが受付中か
• 出荷準備中か
• 決済済みか
• 管理者ユーザーか一般ユーザーか
• キャンセル期限内か期限後か

この前提を書かずに手順だけを書くと、レビューで「どの状態のデータで確認するのか」と指摘されます。

差し戻される理由3：条件分岐が網羅されていない

テストケースレビューでは、条件分岐が見られます。

仕様に条件がある場合、その条件ごとに確認が必要かを判断します。

すべての組み合わせを機械的に増やす必要はありません。ただし、仕様上結果が変わる条件は、レビューで説明できるようにしておく必要があります。

差し戻される理由4：テストデータが曖昧

テストケースに手順と期待結果が書かれていても、テストデータが曖昧だと実施できません。

たとえば「対象データを選択する」と書かれていても、どの状態のデータを使うのか分からないと、実施者が迷います。

実務では、次のような情報が必要になることがあります。

• 対象データのID
• データのステータス
• 権限を持つユーザー
• 事前に登録しておく値
• テスト後に確認する値
• テスト後に戻す必要があるデータ

テストデータが明確だと、レビューする側も実施する側も確認しやすくなります。

差し戻される理由5：仕様との対応が分からない

テストケースは、仕様と対応している必要があります。

レビューでよくある指摘が「このテストは何の仕様を確認していますか」というものです。

テストケースが多くても、どの仕様を確認しているのか分からないと、抜け漏れを判断できません。

私は、テストケースを作るときに次のどれかを紐づけるようにしています。

• 仕様書の章番号
• 機能ID
• 画面項目名
• 業務ルール
• 確認したい条件分岐

仕様との対応があると、レビューで説明しやすくなります。

レビュー前のセルフチェック

テストケースをレビューに出す前に、私は次の観点で確認します。

• 何の仕様を確認するテストか分かるか
• 前提条件が書かれているか
• 手順が再現できるか
• 期待結果が判断できる表現になっているか
• 必要なテストデータが分かるか
• 正常系だけでなく例外系もあるか
• 条件分岐が不足していないか
• 実施後に確認する画面やDBが明確か

このチェックをしてからレビューに出すだけでも、差し戻しはかなり減らせます。

AIで作ったテストケースも必ずレビューする

AIを使うと、テストケースのたたき台を短時間で作れます。

ただし、AIが作ったテストケースは、一般的な観点に寄ることがあります。その案件固有の権限、データ状態、業務ルール、既存機能への影響までは、人が確認する必要があります。

AIを使う場合は、次のように依頼するとレビューしやすくなります。

以下の仕様について、正常系、入力チェック、権限、ステータス、例外系、既存機能への影響に分けてテストケース案を作成してください。各ケースには前提条件、操作手順、期待結果、必要なテストデータを含めてください。

AIでテストケースを作る具体的な流れは「AIでテストケースを作る方法」も参考になります。

まとめ：テストケースはレビューで説明できる形にする

テストケースレビューで差し戻される理由は、テストの数が少ないことだけではありません。

期待結果が曖昧、前提条件が足りない、条件分岐が抜けている、テストデータが分からない、仕様との対応が見えない。このような状態だと、実施できるテストケースになりません。

実務で求められるテストケースは、誰が実施しても同じ判断ができるものです。

レビューで指摘されることを避けるためではなく、後から不具合を見逃さないために、前提条件、手順、期待結果、テストデータを明確にしておきましょう。