「単体テストは通った。でも、画面やDBまで全部試すべき？」
改修のたびに、どこまで確認すればよいか迷うことがあります。
先に結論
- 見つけたい失敗から、確認する範囲を選ぶ。変更した行数やケース数だけで決めない。
- 実物とモックを明記する。「単体・結合」は確認する範囲、「手動」は実施方法として分ける。
- 未確認のリスクも残す。省く確認は、判断する人と補う方法をセットで相談する。
この記事では、架空の問い合わせ管理を使い、入力・権限・検索の3つの改修からテスト範囲を考えます。確認を省くときの伝え方も、記入例で示します。
見つけたい失敗からテスト範囲を選ぶ
同じ問い合わせ機能でも、入力エラーの表示漏れ、権限のない更新、他人の問い合わせの混入では、見つけたい失敗が違います。その失敗を検出できる場所で試すのが、範囲を決める出発点です。
題材は、件名が必須で1〜100文字、状態が「下書き・受付済み・対応中・完了」で、投稿者と担当者がいる問い合わせ管理です。以下はそれぞれ独立した架空の改修で、実施範囲を相談するための案です。
単体・結合・手動はどう違う？
「単体」「結合」の呼び方はチームごとに揺れるため、名称だけで合意せず、何を実物で試すかを揃えます。この記事では次の意味で使います。
- 単体：業務判定などを、狭い範囲で確認する。
- 結合：Controllerと変換処理、Repositoryと実DBなどのつながりを確認する。
- 手動：人が操作して確認する方法。画面操作は自動化する場合もある。
「結合テスト済み」だけでは、実DBまで試したかは伝わりません。「Controllerは実物、Serviceはモック、DB未接続」と書くほうが確実です。
分類や回帰確認の考え方は、ISTQB Foundation Levelシラバスの2.2節で確認できます。
3つの改修で、確認する範囲を考える
例1：件名の入力エラー表示を整える
- 見つけたい失敗：不正入力が通る。エラーの理由が見えない。入力済みの値が消える。
- 主な確認：既存判定の回帰。Controllerのエラー応答。画面の入力保持と表示。
- 残るリスク：実ブラウザで試していなければ、配置や操作性は未確認。
表示文だけを変える場合も、訂正して保存できるところまで確認します。判定のロジックを変えないなら、既存の判定テストを大量に書き直す必要があるかは、変更内容から判断します。
例2：「対応開始」を現在の担当者だけに許可する
- 見つけたい失敗：投稿者や他人が更新できる。拒否したのに状態が変わる。
- 主な確認：Serviceの権限・状態判定。認証された利用者との対応。DBの更新有無。
- 残るリスク：Repositoryをモックした確認だけでは、保存後の状態は分からない。
現在の担当者が、受付済みの問い合わせを対応中へ進められることを確認します。投稿者というだけでは許可しません。無関係の利用者、担当者未設定、下書きや完了状態からの操作も試します。
拒否時はエラーが返るだけでなく、元の状態が変わらないことも期待結果です。Serviceを狭い範囲で試す書き方は、ServiceをJUnit・Mockitoでテストする方法を参照できます。
例3：「自分が担当する問い合わせ」で一覧を絞る
- 見つけたい失敗：他人の行が混ざる。0件で失敗する。並び順が変わる。
- 主な確認：Repositoryと対象DBの検索。Serviceから渡す条件。画面の絞り込み。
- 残るリスク：少量データの確認だけでは、本番規模の速度は分からない。
担当者20の行、担当者30の行、担当者なしの行を用意し、検索結果にどれが入るかを確かめます。対象者が0件のときの結果も確認します。
単体で通れば十分？
Serviceの判定が正しくても、Controllerが認証された利用者ではなく、リクエスト本文の利用者IDをそのまま渡していたら、想定した権限確認にならない可能性があります。利用者の情報が業務判定へ届く経路も、実際の構成で試します。
ここに注意
「保存を呼ばなかった」と「実DBで更新されなかった」は別の証拠です。モックでの確認だけで保存結果を保証せず、別経路の更新やトランザクションは、その境界で確認します。
組み込みDBだけでは、対象DBに固有のSQL、照合順序、ロックの動作まで保証できません。そこが変更点なら、対象DBの検証環境を範囲に含めます。
MockMvcは実HTTPサーバーを起動せず、Spring MVCの処理を試す仕組みです。Spring公式のMockMvc説明にあるとおり、組み込むControllerや設定によって確認範囲が変わります。実ネットワークやブラウザまで通したとは限りません。
入力エラーのテストが403や400で止まる場合は、MockMvcでPOSTが403・400になる原因を確認してください。目的の処理に届いていないのに期待値を現状へ合わせると、確認したかった内容を失います。
画面では、操作を完了できるかを見る
件名のエラーが入力欄の近くに出るか、入力が保持されるか、訂正して保存できるかを見ます。対応開始なら、状態表示が更新されるか、拒否された理由が分かるかを確認します。
細かな判定を自動テストで確認し、画面では代表ケースで一連の操作を試す構成も考えられます。ただし、画面表示そのものが主な変更なら、実際の表示を省く理由は慎重に扱います。
手動の記録も「問題なし」で終わらせず、環境・利用者の役割・事前状態・操作・観察した結果を残します。
省くテストは、残るリスクと一緒に相談する
期限が厳しいときも、今回の変更で守るべきことから優先順位を決めます。担当者以外の更新を防ぐ改修なら、権限と更新結果の確認が重要です。表示文だけの変更なら、無関係な性能試験を毎回行う必要性は低いかもしれません。
案件の契約、障害の影響、既存の自動テストも踏まえ、未実施を合格に見せず、判断する人と補う方法を付けます。
記入例｜確認済みと未確認を分けて伝える
一覧検索の確認範囲を相談する、架空の記入例です。
- 確認済み：実DBで担当者別・担当者未設定・0件の検索を確認。
- 確認予定：主要ブラウザ一つで表示を確認する。
- 未確認：大量データの性能試験は未実施。応答時間の悪化は判断できない。
- 判断者と次の確認：運用規模と既存の計測結果を確認し、担当リーダーが追加試験の要否を判断する。
完了時には、変更したところが直った確認と、周辺が壊れていない回帰確認を分けます。ケース数や網羅率だけで十分と断定せず、何を確かめ、何が残ったかを伝えます。
提出前の5点チェック
- 今回の改修で、見つけたい失敗を挙げたか。
- それぞれを、どの範囲・方法で確認するか決めたか。
- 実物とモック、DBやブラウザを試した範囲を明記したか。
- 変更内容に応じて、正常系だけでなく拒否時の動作や周辺への影響も確認したか。
- 未確認のリスク、判断者、補う確認を残したか。
入力と業務の境界を見直したい場合は、ControllerとServiceの入力チェックも役立ちます。
