はじめに
こんな経験ありませんか？
- 「どの環境でテストしましたか？」と聞かれて答えられない
- 「検証データは何を使いましたか？」と言われて焦る
- 前回NGだったのに今回OKになった（あるいはその逆）
- 再鑑（さいかん）のとき、確認観点が変わってて結果が変わった
テストは「動いた / 動かなかった」だけを確認するものではありません。
どこで・何を使って・どう確認したか がセットで記録されていないと、
チームで品質を担保することができません。
この記事では、新人エンジニアが押さえておくべき
「テスト環境・検証データ・再鑑の前後差分」について整理します。
① テスト環境とは何か
環境の種類
| 環境名 | 略称 | 用途 |
|---|---|---|
| ローカル環境 | local | 自分のPCで動かす。開発中の動作確認 |
| 開発環境 | dev | チーム全員が使う開発用サーバー |
| テスト環境 | test / stg | テスト専用。本番に近い構成 |
| ステージング環境 | stg / staging | 本番直前の最終確認用 |
| 本番環境 | prod / production | 実際のユーザーが使う |
⚠️ どの環境でテストしたかを必ず記録する
「ローカルではOKでした」はテスト完了ではありません。
環境ごとの違いがバグを生む
ローカル → dev → test → stg → prod
環境が変わるたびに以下が変わる可能性がある：
・データベースの内容（レコード数・初期データ）
・設定ファイル（接続先URL・認証情報）
・OSやミドルウェアのバージョン
・他システムとの連携有無
実際によくある事故：
❌ ローカルではOKだったのに、テスト環境でNGになった
→ 環境変数の設定が違った
❌ テスト環境でOKだったのに、本番でNGになった
→ 本番だけデータ量が多く、処理が遅くなってタイムアウトした
テスト結果に必ず書くべき環境情報
■ テスト実施環境
環境名：テスト環境（test）
URL / サーバー名：http://test.example.com
OS：Windows 10 / CentOS 7
ブラウザ：Chrome 120.0 / Firefox 121.0
アプリバージョン：v2.3.1
テスト実施日：2025年03月06日
実施者：山田 太郎
② 検証用データとは何か
なぜ検証データが重要なのか
同じ機能をテストしても、使うデータが違えば結果が変わります。
例：会員登録フォームのテスト
データA：正常な値（名前あり・メール形式正しい）→ OK
データB：名前が空欄 → バリデーションエラーを確認
データC：メールアドレスに@がない → バリデーションエラーを確認
データD：名前が100文字以上 → 上限チェックを確認
データE：すでに登録済みのメールアドレス → 重複チェックを確認
どのデータで試したかを記録していないと、
「どのパターンを確認済みか」が誰にもわからなくなります。
検証データの種類
| データ種別 | 説明 | 目的 |
|---|---|---|
| 正常系データ | 正しい形式・正しい値 | 正常に動くことを確認 |
| 異常系データ | 空欄・形式不正・範囲外の値 | エラー処理を確認 |
| 境界値データ | 最小値・最大値・その±1 | 境界でのバグを確認 |
| 既存データ | DBにすでにあるレコード | 重複・競合を確認 |
| 大量データ | レコード数が多い状態 | 性能・タイムアウトを確認 |
検証データの記録テンプレ
■ 使用した検証データ
No. | データ内容 | データ種別 | 結果
----|------------------------|-----------|------
1 | 名前：山田太郎 / 正常値 | 正常系 | OK
2 | 名前：（空欄） | 異常系 | OK（エラー表示を確認）
3 | メール：test_example.com | 異常系 | NG（エラーが出なかった）
4 | 名前：あ×101文字 | 境界値 | OK（上限エラーを確認）
③ 再鑑（さいかん）とは何か
再鑑の意味
再鑑（さいかん）＝ 一度確認した内容を、もう一度確認しなおすこと
テストの文脈では主に：
- NGだった箇所を修正した後にもう一度テストすること（再テスト・リテスト）
- 別の担当者が同じ観点で確認しなおすこと
ほぼ同じ意味で使われる言葉：
| 言葉 | ニュアンス |
|---|---|
| 再鑑 | 確認しなおす（広い意味） |
| 再テスト | 同じテストをもう一度やる |
| リテスト（retest） | 修正後の動作確認 |
| 回帰テスト（regression test） | 修正によって他の箇所が壊れていないかの確認 |
④ 前と後で試験結果が違うとき
なぜ結果が変わるのか：4つの原因
パターン1：修正が反映された（正常）
before：NG（バグがあった）
after ：OK（修正されてバグが直った）
→ これは正常。変化の理由を記録しておく。
パターン2：確認観点が変わってしまった（要注意）
before：「ボタンを押したとき、エラーが出ないこと」を確認 → OK
after ：「ボタンを押したとき、正しいページに遷移すること」を確認 → NG
→ 同じ操作でも、見ているポイントが違う！
結果の比較をするときは確認観点を揃える必要がある。
再鑑で観点がずれるとこうなる：
担当者A（初回）：ログインできるか確認 → OK
担当者B（再鑑）：ログイン後に正しい画面が出るか確認 → NG
→ 結果が違うのは当然。でも「前はOKだったのに！」で混乱しがち。
パターン3：環境・データが変わった
before：テスト環境A のデータで確認 → OK
after ：テスト環境B のデータで確認 → NG
→ 環境や使ったデータが違うと、結果も変わる。
パターン4：別の修正が影響した（デグレード）
before：〇〇機能 OK
↓ 別のバグを修正
after ：〇〇機能 NG
→ 修正によって別の場所が壊れた（デグレード）
これが回帰テストをやる理由。
前後で結果が違ったときの報告テンプレ
■ 再鑑結果：前後差分報告
対象機能：〇〇機能 / 〇〇画面
初回テスト日：YYYY/MM/DD 担当：〇〇
再鑑テスト日：YYYY/MM/DD 担当：〇〇
【結果比較】
項目 | 初回 | 再鑑 | 変化
-------------------|---------|---------|------
テスト件数 | 10件 | 10件 | 変化なし
NG件数 | 3件 | 1件 | 改善
OK件数 | 7件 | 9件 | 改善
【差分の理由】
・2件が修正により OK に変化
・残り1件は調査中
【確認観点】
初回・再鑑ともに同じ観点で確認済み（テスト仕様書 v1.2 に基づく）
【使用環境・データ】
環境：テスト環境（test）※初回・再鑑とも同じ
データ：テストデータセット v1.0 ※初回・再鑑とも同じ
⑤ チェックリスト：「前と後で結果が違う」ときの確認項目
□ 同じ環境でテストしているか？
□ 同じ検証データを使っているか？
□ 確認観点（テスト仕様）は同じか？
□ アプリのバージョンは同じか？
□ 初回と再鑑の手順は同じか？
□ 別の修正がデグレードを起こしていないか？
□ 結果の変化した理由を記録したか？
まとめ
| テーマ | ポイント |
|---|---|
| テスト環境 | どの環境でやったか必ず記録する |
| 検証データ | 何のデータで確認したかをセットで残す |
| 再鑑 | 確認観点・環境・データを初回と揃える |
| 前後差分 | 結果が変わった理由を必ず記録する |
テストで大事なのは「動いた」より「どこで・何で・どう確認したか」。
この記録があれば、前と後で結果が違っても、
「なぜ変わったのか」をチームで正確に説明できます。
---