1000個のエラー、1つのGoogleスプレッドシート、そして二度と戻らない5時間
すべてのバグには物語がある。その多くは、「自分の環境では動いているんだ」という言葉から始まる。
私たちは、リードジェネレーション（見込み客獲得）企業向けのデータインポート機能をテストしていた。その機能は単純に見えた。インポートボタンをクリックし、スプレッドシートをアップロードすれば、システムが連絡先を読み込む。誰もが「うまくいく」と思い込んでいた。
その思い込みこそが罠なのだ。
テスターの存在意義は、その思い込みを打ち砕くことにある。「ハッピーパス（正常系）」は、常にあなたに嘘をつく。
きれいなExcelファイルを使えば、インポートは成功した。そのまま昼食に行けたかもしれない。機能をリリースできたかもしれない。しかし、もしそうしていたら、月曜日の朝、本番環境で顧客がバグに遭遇していただろう。
問題はGoogleスプレッドシートだった。
実際のユーザーは、整理されたExcelファイルなど使わない。彼らが使うのは、ぐちゃぐちゃなGoogleスプレッドシートだ。彼らは、システムが自分たちのカオス（混乱）を処理してくれることを期待している。
Googleスプレッドシートのデータをアップロードした瞬間、システムは失敗した。1,000件を超えるエラーが表示され、画面はエラーで埋め尽くされた。ボタンもデータ型も同じなのに、ソースのフォーマットが変わっただけで、システムは完全に崩壊した。
私たちはExcelに戻ってさらにテストを行った。有効な行と無効な行を混ぜて試してみたが、システムはうまく処理した。不正な行をスキップして次に進んだのだ。
次に、現実世界の「カオス」を試した。数百行ある一括ファイルをアップロードした。そのほとんどはゴミデータで、まともなものは数行しかなかった。
システムは完全に壊れた。バリデーション（検証）ロジックは数行の不正なデータには対応できたが、大量の不正データの山を前にして力尽きた。
私たちは根本原因を突き止めるのに5時間を費やした。画面を凝視し、テストをやり直し、ファイルやブラウザ、さらにはコーヒーのせいにしては悪態をついた。
その5時間は、安いものだった。そうでなければ、顧客が午後の時間を台無しにし、私たちの製品への信頼を失うことになっていたのだ。テスト段階のバグは「時間」で支払う。本番環境でのバグは「顧客」で支払うことになる。
私は、いつでも5時間の道を選ぶ。
優れたテスターは、機能が「動くか」は問わない。優れたテスターは、どうすれば「壊せるか」を問う。
開発者のように考えるのをやめよう。次のような人々の視点で考え始めてほしい：
- 間違ったファイル形式をアップロードする怠慢なユーザー。
- セルの結合や空行だらけの、カオスなデータを使うユーザー。
- きれいな10件ではなく、汚いレコードが4,000件ある一括データを扱うユーザー。
- やってはいけないことを、あえて実行するトラブルメーカー。
ソフトウェアは、予想もしなかった入力によって壊れる。
最も「単純」に見える機能こそ、しばしば最も危険だ。インポートボタン、検索ボックス、問い合わせフォーム。これらは無害に見えるが、決してそうではない。
もし機能がハッピーパスを通過したとしても、そこで満足してはいけない。「もし、想像しうる最悪のファイルをアップロードしたらどうなるだろうか？」と問いかける人間になれ。
そして、実際にやってみるのだ。
Optional learning community: https://t.me/GyaanSetuAi