作成したソフトウェアのテストを行うためのコードは、ソフトウェアの動作には関係ないということで品質が軽視されがちなもの。そんなテストのためのコードが原因でとんでもないトラブルを引き起こしてしまったという経験を、エンジニアのシャントヌ・ティワリさんがブログに書いています。
The Day My Script Killed 10,000 Phones in South America
https://new.pythonforengineers.com/blog/the-day-i/
ティワリさんが開発していたのは携帯電話会社向けの、盗まれたり支払いが滞ったりしたスマートフォンを遠隔でロックするアプリ。Androidの一部としてインストールされているため、ユーザーが勝手にアンインストールすることはできず、電話機能やWi-Fi機能など低レベルな機能を制御することも可能な権限がありました。
ティワリさんの勤めていた会社はアプリそのものの開発だけでなく、オペレーターが操作するためのウェブアプリも開発しており、開発会社の社内ではどちらのアプリも上手く動作していたとのこと。しかし、韓国のとある携帯電話会社が、その会社が開発したオペレーション用のツールをテストするように要請してきたそうです。ティワリさんはそのツールの出来に内心閉口しながらも、業務命令には逆らえず、ツールのテストを担当することになりました。
そんな中、ティワリさんの勤めていた企業が投資会社に買収され、全てのプロジェクトの期限が繰り上げられました。ティワリさんのチームは全く異なる3つのプロダクトを同時にテストすることになり、時間の都合で「成功ケース」だけを検証するようになったとのこと。
ある時、オペレーターがCSVファイルをアップロードすることで複数台のスマートフォンをまとめてロックする機能をテストすることになりました。ティワリさんはPythonでランダムな電話番号を生成するコードを作成。ポータルサイトにログインしてロック機能を試し、別のポータルサイトにログインして結果を確認するという手順でテストを行いました。ティワリさんはこの手順をスクリプトにし、数時間かけて何万件ものケースをテストできるようにしていたとのこと。
期限までの時間がなかったため、そのスクリプトについてのチェックは行われておらず、ティワリさんがスクリプトを書き上げた10秒後にはそのスクリプトが実行されているような状態だったそうです。スクリプトの実行結果は良好で、マネージャーの確認も済んで週末に入ろうとしたとき、ティワリさんは「南米で何千台ものスマートフォンがロックされている」というメールを受け取りました。
ティワリさんがランダムに生成した番号は、実際に南米で利用されているものであったため、大規模なスマートフォンのロックが起きてしまったというわけ。テストに利用したCSVファイルがすべて残っていれば逆にロック解除用のスクリプトを書くことで対応できたのですが、ティワリさんはテストごとに新たに生成した番号でCSVファイルを上書きしており、最後の回の分しか残していなかったそうです。
幸い、韓国の携帯電話会社のサイトからロックした電話番号を100件ずつダウンロード可能なことが分かったため、ダウンロード用のスクリプトとロック解除用のスクリプトを作成。同僚の助けもあり、1時間ほどですべて対応できたとティワリさんは書いています。
ティワリさんはこの件から、「テストスクリプトは通常のコードと同様の注意を払う必要がある」「重要なテストを期限に迫られている時にやってはいけない」「携帯電話会社は自社の管轄外のスマートフォンもロックできる」という教訓を得たとのこと。
さらに再発防止策として、「テストは各コンポーネントから最終的なシステムへと段階的に行う」「成功パターンだけでなく失敗パターンもテストする」「都合のいい仮定を置かない」「開発環境を本番環境とは別に用意してそちらでテストを行う」という点を述べています。
なお、ティワリさんの当時勤めていた会社はその後もプロジェクトの期限を厳しく設定してきたため、事故の発生後もティワリさんはこうした教訓や再発防止策のことは完全に忘れることにして成功パターンを確かめるという「テストのふり」を続けたとのことです。
この記事のタイトルとURLをコピーする
