1000個のエラー、1つのGoogleスプレッドシート、そして二度と戻らない5時間
すべてのバグには物語がある。今回の物語は、「自分の環境では動いている」という嘘から始まった。
私たちは、リードジェネレーション（見込み客獲得）企業向けのデータインポート機能をテストしていた。一見、単純なものに思えた。ボタンをクリックし、ファイルをアップロードすれば、データが読み込まれる。
ほとんどの人は、こうした機能は正常に動作するものだと想定している。テスターの存在意義は、その想定が間違っていることを証明することにある。
「ハッピーパス（正常系）」は罠だ。
きれいなExcelファイルをアップロードすれば、システムはパスする。あなたは昼食に出かけ、仕事が終わったと思うだろう。しかし、そこで止まってしまえば、壊れたコードをリリースすることになる。月曜日の朝、本番環境で顧客がそのエラーを見つけることになるのだ。
問題は、Googleスプレッドシートだった。
実際のユーザーは、整理されたExcelファイルなど使わない。彼らが使うのは、ぐちゃぐちゃなGoogleスプレッドシートだ。スプレッドシートの中に混沌を作り出し、システムがそれを処理してくれることを期待している。
Googleスプレッドシートをアップロードしたとき、システムは失敗した。1,000件を超えるエラーが発生したのだ。データもボタンも同じなのに、フォーマットが変わっただけでシステムは完全に崩壊した。
次に、データの品質をテストした。
- 数行の無効な行？ システムはそれらをスキップして次に進んだ。
- 何百もの乱れた行？ システムは壊れた。
バリデーションロジックは、小さなエラーに対しては機能していた。しかし、大量のゴミデータに直面したとき、それは失敗した。
私たちはこのデバッグに5時間を費やした。ファイル、ブラウザ、データのせいにした。コーヒーのせいさえした。
その5時間は安上がりだった。そうでなければ、もっと高い代償を払うことになっていた。もし顧客がこのバグを見つけたら、製品への信頼を失う。テスト段階のバグは「時間」で支払う。本番環境でのバグは「顧客」で支払うことになる。
私は、時間で支払う方を選ぶ。
本物のバグを見つけるには、マインドセットを変えなければならない。「ソフトウェアが動作するか」を問うのではない。「どうすれば壊せるか」を問うのだ。
開発者のように考えるのをやめ、次のような人物として考え始めてほしい。
- 間違ったファイル形式をアップロードする怠惰なユーザー。
- セルの結合や空行だらけのスプレッドシートを使う混沌としたユーザー。
- きれいな10件ではなく、汚れた4,000件のレコードを扱う大量データユーザー。
- やってはいけないことを、あえて実行するトラブルメーカー。
ソフトウェアは、予想もしなかった入力によって壊れる。
「単純な」機能こそが最も危険だ。インポートボタンや検索ボックスは無害に見えるが、そうではない。
次に機能がハッピーパスを通過したら、「想像しうる最悪のファイルをアップロードしたらどうなるか？」と問いかける人間になってほしい。
そして、実際にやってみるのだ。