　上記のいずれも一度は経験する常連バグでしょう。テストのバグの特徴は、プログラムのバグとの区別がつきにくいことや、場合によってはテストの信頼性が失われることです。例えば、「そもそもの入力値が間違っていた」「テストするバージョンが違っていた」「テスト項目に転記ミスがあった」「ケーブルを接続していなかった」などです。

　傾向と対策は以前示しましたので、今回は、筆者のやってしまったケーススタディー集を中心とします。

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

4.1 操作ミスが原因だった

　コンソール上で動作するプログラムを開発していたときの話です。テストをする際に、効率を上げるため、コマンドをExcelにまとめ、コピペで実行していました（図1）。

図1　テストの実施イメージ（左：プログラムの実行画面、右：テスト項目）（クリックで拡大）

　図1は、テストの実施イメージです。左の図は、コンソール画面からプログラムを実行している様子で、右はコマンドをまとめたExcelシートを表しています。テスト項目に合わせて、セルにカーソルを合わせ、キーボードの「Ctrl＋c」でコマンドをコピーし、「Alt＋Tab」でウィンドウをコンソールに切り替え、「Ctrl＋v」でコマンドをペーストしてテストしていました。

　テストを始めて3時間ぐらいが経過し、テストに慣れてきたころ、突然、プログラムが停止しました。「プログラムのバグかな……」と思いましたが、原因は違いました。

　原因は、テスト手順の途中に、コンソール画面で「Ctrl＋c」を押し、これによりプログラムが終了したのです^※2）。つまり、コマンドをコピーしたのではなく、コンソール画面で終了コマンドを入力してしまったのです。

　そこで、統合開発環境から実行することにより「Ctrl＋c」の誤入力への対策としました（統合開発環境からの実行では、Ctrl＋cはプログラム終了ではないため）。

※2）コンソール画面では、「Ctrl＋c」を入力するとプログラムの終了コマンドとなります。主に、無限ループのプログラムを終了する場合に使いますね。

4.2 テスト項目の実施抜け

　同じテスト手順を何度も繰り返すと、人間は飽きてくるものです。その際、頻発するのがテスト手順の抜けです（表4）。例えば、ログの起動し忘れでしょう。


No.	手順	確認結果
1	初期設定値を変更する
2	プログラムを起動する
3	指令値入力する
4	ログを起動する
5	動作を開始する
5	プログラムを停止する
6	ログ停止
7	ログからテスト結果の評価をする
表4　テスト手順