ソフトウェア技術者のためのバグ百科事典(18)開発工数の半分を占めるテストのバグのケーススタディー:山浦恒央の“くみこみ”な話(139)(3/3 ページ)
ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第18回は、開発工数の半分を占めるテストのバグのケーススタディーを紹介します。
4.3 手順のスキップが危うく大惨事
筆者が複数人で1つの製品をテストしていたときの例を挙げます。
テストの途中で、別の作業員が手順を確認していました、筆者はいつもと同じテストだったので、待機していました。その待機中、筆者に同僚からの着信があり、「待機中なので電話に出ても構わないだろう」と通話を始めました。30秒経過したころ、「そろそろテスト再開するよ」という無言の視線を感じました。電話の相手の同僚に「後でかけ直す」と伝え、テストを再開したところ、全く意図しない動作をしました(図2)。
図2は、テスト手順のフロー図を表したものです。原因は、「入力値の設定」手順をスキップして電話をしてしまい、その後、入力値の設定をした「つもり」になっていました。「つもり」は、本人がそう確信しているため、非常に厄介ですね。
このテストでは、入力値を設定することで機器の目的地を設定していました。手順が抜けた結果、目的地が初期値の0となり、下手をすれば機器を破壊して大惨事となるところでした。
以降、筆者は心を入れ替え、大事なテスト中には電話に出ないと心に誓いました。
4.4 テスト手順がシビア
あるモードに遷移してから4秒以内にスイッチをONにするテストがありました。筆者は、このテストを実施するのが初めてで、「なるべく早くやらないと」と思いました。いざテスト本番となり、素早く実行すると、思い通りの結果となりません。原因を担当者に確認したところ、「あまりに早くスイッチを押すとうまくいかない」と聞き、ガックリしました。
4.5 自分は何をやっているのだろう……
筆者は反復作業が苦手です。特に、疲労がたまると、「自分は今何をやっているのだろう」と考え込むことも少なくありません。例えば、そんなときに起こるのが、次の表5のケースです。
No. | テスト項目 | 入力値1 | 入力値2 | 期待値 | 出力値 | 良否 |
---|---|---|---|---|---|---|
… | … | … | … | |||
20 | 加算処理を確認する | 1 | 2 | 3 | 3 | OK |
21 | 10 | 20 | 30 | 3 | NG | |
… | … | … | … | |||
表5 テスト項目例 |
筆者は、表5のようなテスト項目を見ながら、黙々とテストをしていました。No.21のテストを実施し、出力値を確認したところ、期待値と一致しません。テスト項目を再確認すると、そもそも実施するべきテスト項目はNo.20だったことに気付き、自分の疲れがピークに達したと痛感しました。
4.6 テスト入力値の設定ミス
プログラムの起動前に初期設定値を入力する必要があるプログラムがありました(図3)。
図3は、プログラム実行前に使用する設定値のイメージです。左がテスト項目に記載してある設定値で、外部入力ファイルに転記してテストする予定でした。
ファイルに値を転記し、実行したのですが、思い通りに動作しません。「修正のミス」「設定値のミス」「プログラムのバグ」を疑いましたが、原因は分かりません。次の日、もう一度よく確認すると、そもそも、入力すべきデータ名称が逆順になっており、間違った値を設定していました(図4)。
図4は、外部入力ファイルの設定値です。よく見ると分かる通り、意図しないデータ値を設定しています。なぜ、逆順に書いたのか、今でも不思議です。
5.終わりに
テスト業務は、ソフトウェア開発の中でも地味で、長時間にわたる根気と労力が必要な作業です。その作業の中でも、今回は、テストのバグのケーススタディーを紹介しました。
組織によってやり方は異なるため、全て当てはまらないとは思いますが、以下に注意してテストをしましょう。
- 機器を壊す可能性のあるテストは、複数人でダブルチェックして慎重に実施する
- 適度な休憩を取る
- テスト最中に、むやみに新しいテスト項目を増やさない
- 可能な限り自動化する
上記に気を付けて、よりよいテスト業務となれば幸いです。
本コラムでバグに関して興味を持った方は、バグ検出テキスト(書籍)や、過去記事(第122〜第138回)をご参照いただければと思います。
山浦先生の新刊「ソフトウェア技術者のためのバグ検出テキスト」が発売!
本シリーズ「ソフトウェア技術者のためのバグ百科事典」を大幅に加筆、修正した山浦恒央先生の新刊「ソフトウェア技術者のためのバグ検出テキスト」が日科技連出版から発売されました。連載でも取り上げた、「要求仕様書のバグ」「実装抜けのバグ」「テスト業務のバグ」など、バグを36種類に分類して解説しました。囲碁や将棋であれば、「相掛かり」「矢倉」「四間飛車」「藤井システム」のような戦法を網羅した内容になっています。
前著「ソフトウェア技術者のためのバグ検出ドリル」(2019年11月刊行)も好評発売中です。実際にバグを含む要求仕様書、設計書、コーディング、デバッグ、保守を具体的に取り上げ、練習問題として31問を出題しました。同書は、囲碁や将棋における「次の一手」的な問題であり、ピンポイントの場面を取り上げ、実践力を鍛えることを目的としています。
両書とも興味のある方は、Amazon.comや書店でチェックしてください!
東海大学 大学院 組込み技術研究科 非常勤講師(工学博士)
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- ≫連載「山浦恒央の“くみこみ”な話」バックナンバー
- ソフトウェア技術者のためのバグ百科事典(8)バグを見つけるテストがバグってる
ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第7回は、プログラムのバグを見つける作業である「テスト」がテーマです。テストの作業次第では逆にバグを作り込むこともあり、「テストのテストのテスト」のように無限ループに陥りかねません。 - ソフトウェア技術者のためのバグ百科事典(17)無限ループやbreak抜け、コーディングのバグ再び
ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第17回は、第14回でテーマにしたコーディングのバグを再び取り上げます。無限ループやbreak抜けなどまだまだあります! - ソフトウェア技術者のためのバグ百科事典(16)青海青梅問題もビックリ、勘違いが原因のバグ
ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第16回は、誰もが経験する「勘違い」に起因するバグを取り上げます。たかが勘違いといっても大事件につながる可能性もあるので要注意! - ソフトウェア技術者のためのバグ百科事典(15)最大の試練、仕様変更で起きるバグ
ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第15回は、ソフトウェア開発で最も大きくて深刻な問題が発生する原因であり、エンジニアには厳しい試練となる、仕様変更で発生するバグを取り上げます。 - ソフトウェア技術者のためのバグ百科事典(14)地獄の作業と化すコーディングのバグ
ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第14回は、プログラマーの花形的なプロセスであるコーディングのバグを取り上げます。