ソフトウェア技術者のためのバグ百科事典（8）バグを見つけるテストがバグってる：山浦恒央の“くみこみ”な話（129）（3/4 ページ）

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

※本記事はアフィリエイトプログラムによる収益を得ています

4．テスト業務のバグのケーススタディー

　恥ずかしいことですが、筆者は、先述した4つのパターン全てのバグを作ったことがあります。以下、筆者の失敗談を紹介します。

4.1 テスト入力値を間違えた……

　ある条件を入力すると、異常処理を起こすテスト項目を作成していたのですが、異常になりません。プログラムのバグと思い、ソースコードの処理内容を見直すと、この入力条件では異常処理とならないことが分かりました。結果、テスト項目を修正して再テストしました。テストの入力値が正しければ、ソースコードを細かく見る必要はなく、余計な時間をかけることもありませんでした。

4.2 タイムスタンプを確認したら……

　プログラムの細部を修正後、テストをすると、修正が反映されていないことが分かりました。「修正不十分だったのかな」と思い、ソースコードを細かく見直すと、修正は問題なさそうでした。念のため、実行可能形式ファイルのタイムスタンプを確認すると、日付が違っており、間違ったバージョンをテストしていました。「バージョン違い」は、なかなか気が付きません。あちこちを散々チェックした結果、「バージョン違い」が分かった時、ホッとしたのと同時に、自分の不注意に腹が立ちました。

4.3 あの時ちゃんと確認しておけば……

　何回も同じテストを実施していると、疲労やモチベーションの低下で、出力結果が正しく見えることがあります。ある時、テスト項目を見直していると、テスト結果がおかしいことに気付きました。前のバージョンに戻しても同じ結果となり、とても焦りました。このテスト項目は、最初から正しく通っていないのです。この時も、余計な作業が大量に発生し、「あの時ちゃんと確認しておけば……」と強く後悔しました。

4.4 LANケーブルが刺さってない……

　正しいテストするには正しい条件で実行しなければなりません。通信系プログラムを作成していて、データを正しく送信できなかったことがありました。Linuxコマンドの「ping」を打ってもアンサーが来ないため、なぜだろうと思っていたところ、そもそも、LANケーブルを接続していないことが分かりました。お粗末で恥ずかしい失敗ですが、顧客先で起きると、とても焦りますね。