ソフトウェア技術者のためのバグ百科事典（18）開発工数の半分を占めるテストのバグのケーススタディー：山浦恒央の“くみこみ”な話（139）（1/3 ページ）
ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第18回は、開発工数の半分を占めるテストのバグのケーススタディーを紹介します。
1．はじめに
バグ百科事典では、筆者が気になったバグを紹介し、読者の皆さまに「バグの早期発見」と「バグの未然防止」に役立てていただくものです。
少しずつバグの知識が深まってきたと思います。今回は、筆者が今まで経験したテストでのバグのケーススタディーを紹介します。
2．テスト業務の流れ
ソフトウェアの開発業務の中で最も地味な作業が、デバッグやテストの検証系でしょう。このフェーズでは、仕様書などの成果物をもとにテスト項目を作成し、期待結果と一致することを確認します。保守を除くソフトウェア開発工数の中で、テストは40〜50％を占めるため、根気と労力が必要なフェーズです。
今回の本題に入る前に、テスト業務の流れを振り返ります。
2.1 テスト計画を立案する
何事も、計画を立てて、それに合わせて進めることはエンジニアリングの基本です。まず、「何日かかるか（期間）」「人員は何人確保できるか（人月＝コスト）」「テストをどのレベルで終わらせるか（終了基準）」などを決めます。
2.2 テスト項目・テスト手順書を作成する
2.2.1 テスト項目を作成する
計画を立案したら、次はテスト項目を作成します（表1）。
| No. | テスト項目 | 入力値1 | 入力値2 | 期待値 | 出力値 | 良否 |
|---|---|---|---|---|---|---|
| 1 | 加算処理を確認する | 1 | 2 | 3 | ||
| 2 | 10 | 20 | 30 | |||
| 表1 加算処理のテスト項目例 | ||||||
表1には、2つの入力値を加算するプログラムのテスト項目です。「1＋2＝ 3」「10＋20＝30」のように、入力値と期待値を作成します。
テスト項目の設計では、ターゲットにするバグを決め、「そのバグを摘出するにはどんなテストをすべきか？」を意識する必要があります。従って、自分が想像できないバグは検出できません。テストやデバッグの設計は、想像力の勝負であり、「想像力の限界が品質の限界」です。日頃から、あらゆるバグに精通していることが重要です。
2.2.2 テスト手順書を作成する
手順が複雑な場合は、テスト手順書を作成します（表2）。
| No. | 手順 | 実施結果 |
|---|---|---|
| 0 | 実施日時を記載する | |
| 1 | PCを起動する | |
| 2 | プログラムを起動する | |
| 3 | 表1に従った入力値を入力する | |
| 4 | 出力値を確認する | |
| 5 | プログラムを停止する | |
| 表2 テスト手順書例 | ||
表2では、テスト手順書の例を記述しました。機器の起動・終了手順や、入力値などを記載し、確認しながら進めます。この例のように、単純な作業では手順書を作る必要はありませんが、「複数人で1つの製品をテストする」「機器を壊さないようにテストする」というときには必要です。手順書がキチンと書いてあれば、プロジェクトが遅れていて、他のプロジェクトから派遣された助っ人（たいてい、当該プログラムの知識はありません）にも、初日からテストを手伝ってもらえて「即戦力」になります。この他、実施結果を根拠資料として顧客に説明することもできます。
2.3 テストを実施する
テストを実施します（表3）。
| No. | テスト項目 | 入力値1 | 入力値2 | 期待値 | 出力値 | 良否 |
|---|---|---|---|---|---|---|
| 1 | 加加算処理を確認する | 1 | 2 | 3 | 3 | OK |
| 2 | 10 | 20 | 30 | 25 | NG | |
| 表3 テスト項目 | ||||||
表3には、記載した入力値に従って、テストを実行し、その「出力値」と「良否の判定」を記載した例です。「1＋2」を入力し、出力値が期待値と同じ「3」になれば、良否は「OK」で、「10＋20」を入力し、期待値と出力値が異なる場合は、「NG」※1）となります。
※1）海外のエンジニアに、「OK」は通じますが、「NG」は、必ず、「これはなんだ？」と聞かれます。「no goodの略だ」と説明すると納得はしてくれますが、完全な和製英語です。海外に出す文書では、「no good」か「not passed」と書きましょう。
2.4 再テストを実施する
良否判定が「NG」の場合、開発者に知らせて原因を探しますね。例えば、「テスト項目にバグがないか」「プログラムにバグがないか」「ハードウェアが原因か」などを考えます。また、バグの修正後は、再テストを実施し、デグレード（機能後退：それまで正常に動いていた別の機能が動作しなくなること。例えば、「台所の水道の蛇口から水漏れしていたのでパッキングを交換したところ、水漏れは止まったが、2階のトイレの電灯がつかなくなった」のような事象で、解明には時間がかかる）が起きてないか確認することも大事です。
2.5 テスト終了を見極める
一通りテストが終わると、テスト工程を終了できるか判断します。例えば、「予定していたテスト項目を全て消化した」「バグ数が収束した」などから考えますね。
上記が一通りのテスト業務の流れです。なお、組織によって実施方法は異なります。
Copyright © ITmedia, Inc. All Rights Reserved.