はじめに

こんな経験ありませんか？

「どの環境でテストしましたか？」と聞かれて答えられない
「検証データは何を使いましたか？」と言われて焦る
前回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 ※初回・再鑑とも同じ

⑤ チェックリスト：「前と後で結果が違う」ときの確認項目

□ 同じ環境でテストしているか？
□ 同じ検証データを使っているか？
□ 確認観点（テスト仕様）は同じか？
□ アプリのバージョンは同じか？
□ 初回と再鑑の手順は同じか？
□ 別の修正がデグレードを起こしていないか？
□ 結果の変化した理由を記録したか？

まとめ

テーマ	ポイント
テスト環境	どの環境でやったか必ず記録する
検証データ	何のデータで確認したかをセットで残す
再鑑	確認観点・環境・データを初回と揃える
前後差分	結果が変わった理由を必ず記録する

テストで大事なのは「動いた」より「どこで・何で・どう確認したか」。

この記録があれば、前と後で結果が違っても、
「なぜ変わったのか」をチームで正確に説明できます。

---