はじめに
テストは品質を保証する重要な工程ですが、実施する際に 「プログラムの作り的にこのケースは発生しないので、確認しなくてOK」 という認識で進めてしまう事、ありますよね。
こういった思い込みこそが 重大なバグを見逃し、最終的には本番環境での障害に繋がるリスク となります。
プログラムは設計通りに動作するとは限りません。予期しないデータの流入、実装ミス、外部システムの影響 など、思い込みを覆す要因はいくらでも存在します。
「やんなくて大丈夫っしょ」
と思ってテストをサボったことが、誰だって一度は経験があるはずです。
不思議とそういったプログラムほど、障害がおきます。
神はいつだってあなたを見ているのです。
「このケースは発生しない」の思い込み
1. プログラムの実装ミスによる想定外の動作
開発者が 「この処理はこの条件でしか動かないから、テストは不要やろ」 と思っていても、実際には 意図しないコードのバグ や 境界ケース により、想定外の動作が発生することがあります。
例:
- 認識: 「この関数は負の数を受け取ることがないから、負の値のテストは不要」
- 実際: あるルートから想定外の負の値が渡されることが判明。
- 結果: 実行時エラーが発生し、本番環境で障害につながる。
「プログラムがそうなっているから大丈夫」ではなく、「プログラムが本当にその通りに動作するのか？」をテストで証明することが重要です。
2. 変更の影響を見落とすリスク
コードの修正を行うことで、意図せず別の箇所に影響を与えることがあります。しかし、
- 「この部分のロジックには手を加えていないから、影響はないはず」
- 「この関数の呼び出し元は限定されているから、大丈夫」
と判断してテストを省略すると、知らぬ間にバグが発生している可能性があります。
例:
- 認識: 「この変数はグローバルではなくローカルなので、外部からの影響はない」
- 実際: 別の開発者が処理を変更し、想定外のデータが入るケースが発生。
- 結果: 未処理の例外が発生し、サービスが停止。
プログラムの作りがどれだけ堅牢でも、変更の影響範囲を正確に把握し、テストで検証しなければリスクはゼロにはなりません。
まだ開発経験が浅いエンジニアとかで、たまに、プログラムに変更を加えていても、そもそもテストしていない人がいます。
変更加えたら絶対テストしような。その周りの機能も。俺との約束。
3. エッジケースの見落としによる予期しない動作
多くのプログラムでは、通常の動作パターンでは問題が発生しませんが、
極端なケース（エッジケース） では動作が崩れることがあります。
- 「ループ内で配列の範囲外にはアクセスしないはず」
- 「データは必ず一定の形式で渡されるから、フォーマットチェックは不要」
エッジケースのテストを省略すると、実際の運用時に想定外のデータが流れ込み、エラーが発生する可能性があります。
例:
- 認識: 「この関数は常に1つ以上のデータを受け取る」
- 実際: あるケースで空データが渡され、ループ内でエラーが発生。
- 結果: アプリケーションが異常終了。
「こうなることはありえない」と言い切るのではなく、「こうなったときにどう動作するか」をテストで確認しましょう。
「このケースは発生しない」を防ぐための対策
1. パターンテストを徹底する
「このケースは発生しない」と思っても、すべてのパターンを考慮したテストを実施することが重要です。
- 正常系と異常系の両方を網羅する
- 入力値の組み合わせを考慮したテストケースを作成する
- あり得ないと思われるケースもテストしておく
2. 修正箇所にとらわれない
「修正による影響はない」と思い込まず、前後の機能、参照・登録・変更されるデータを使う機能、など
俯瞰してテスト範囲を決める、パターンを洗い出す事が必要です。
最後に
テストって大変ですよね。
テスト嫌いな人もいると思います。
けど、テストサボったところほど、障害が起きるものです。不思議。
ちなみに理解しやすいように、炒飯づくりで例えれないかなぁとおもって考えてみましたが、ダメでした。