「動かない」を、期待した結果・実際の結果・再現手順に分ける
バグを直す最初の一歩は、同じ失敗を確かめられる状態にすること。入力・環境・手順と、期待した結果との差を短く残す。原因の予想は観測した事実と分ける。
用語
- 再現手順
- 同じ問題を確かめるための、前提条件と具体的な操作の順序。
- 最小再現例
- 問題が起きる条件を保ちながら、関係のないコードやデータを減らした例。
- 回帰テスト
- 直した問題が後の変更で再発しないかを確かめるテスト。
図と例
期待した結果と実際の結果を書く → 入力・版・データの状態をそろえる → 失敗を残したまま例を小さくする → 修正後に同じ手順で再確認する
仮定の例：開発環境の版Aで、注文0件のアカウントを開くと500になる。期待は200と空の一覧。同じ版の注文1件のアカウントは成功する。この2条件を記録すると、「DBが壊れた」という未確認の予想より、0件の経路を調べやすい。
実際のサービス・製品では
解説
最初の不具合調査や相談に使う。同じ再現手順を修正後にも実行し、可能なら回帰テストに残す。本番に影響がある場合は、最小化の作業と並行して担当者へ状況を共有する。
「一覧がおかしい」だけでは、0件なのか、順番が違うのか、画面が落ちるのか分からない。期待した結果と実際の結果を並べ、再現手順に必要な入力・データの状態・実行した版を添える。次に、失敗が残る範囲で関係のない処理を減らし、最小再現例を作る。短くしたあとも同じ失敗が起きるか確かめる。たまにしか起きないなら頻度と発生条件を記録する。完全に再現できるまで相談を待つ必要はなく、分かった事実と未確認の点を共有すれば調査を引き継ぎやすい。
トレードオフ
- 元の環境で手順と観測を記録する
- 得るもの：環境やデータに依存する問題も調べ始めやすい
- 払うもの：ほかの人が同じ環境を用意できるとは限らない
- 小さな独立した再現例を作る
- 得るもの：原因候補を減らし、ほかの人も実行しやすい
- 払うもの：削った条件によって問題が消えないか確認する手間がかかる
さらに学ぶ
チェック
注文0件でだけ一覧が500になり、原因はまだ不明。最初の相談に最も役立つ情報は？
- 版・データの条件・手順・期待200と実際500の差
- 「DBの故障だと思う」という推測だけ
- 結果を確認せずに試した修正案だけ
解答と解説
版・データの条件・手順・期待200と実際500の差
同じ失敗を確かめられる情報が調査の出発点になる。DBの故障は観測から確定していない。未検証の修正案だけでは、何を直したいのかと効果を判断できない。