　テスト項目の設計では、ターゲットにするバグを決め、「そのバグを摘出するにはどんなテストをすべきか？」を意識する必要があります。従って、自分が想像できないバグは検出できません。テストやデバッグの設計は、想像力の勝負であり、「想像力の限界が品質の限界」です。日頃から、あらゆるバグに精通していることが重要です。

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階のトイレの電灯がつかなくなった」のような事象で、解明には時間がかかる）が起きてないか確認することも大事です。