テストは2種類ある - PART1

コーディング中の動作確認

これは前のトピックで述べたことですが、ソフトを作るときは少しずつコーディングしては動かしてみるということを繰り返しますね。動かしてみて自分の思い通りの動作と違っていたときは「あれっ？」ということになって、間違っているところを探します。ほとんどの人はこういうことを繰り返しながら、だんだんと完成に近づけていくやり方をしていると思います。私もそうです。

ところでこんなやり方の人はいるでしょうか？

1. とにかく全部をコーディングする（その間コンパイルはしない）
2. 全てのコーディングが終わったらコンパイルして、文法上のエラーを取り除く
3. 実行してみて、動作上の不具合を取り除く
4. テストを行い、仕様と合致するかチェックする

これは、ものすごく効率の悪いやり方です。一見合理的に見えますが、全然そうではありません。なぜなら、複数のバグが絡み合って発生する現象の原因を特定するのは単一のバグによる現象の原因特定よりもはるかに難しいからです。この方法だと、コンパイルが完了した時点でいくつものバグを含んでいる可能性が考えられ（いや、むしろ含んでいるに違いないのですが）、不具合を取り除く作業は困難きわまりないという状況になります。ですから、こまめに動作確認しながら作った方が良いのです。

ホワイトボックステスト

コーディングしながらのこまめな動作確認は、考えようによってはテストの一種です。このようなテスト方法を「ホワイトボックステスト」と言います（聞いたことがあるという人もいるでしょう）。ホワイトボックスというのは、ブラックボックスの反対で、中身がわかっているもののことです。作った本人はプログラムの中身を知っているのでこのように呼ぶのです。

ホワイトボックステストは作った本人の手によるテストなので、本人の意図通りに動作しているのかどうかを確認するためのテストということになります。つまり、自分が書いたプログラムの一行一行が思い通りに動くかどうかの確認です。ですから、ソースコード上の全ての行が必ず一度は実行されるような条件下で動かしてみなければ意味がありません。実際、ほとんどの人は無意識にそのような動作チェックをしているのではないでしょうか。

このようなこまめな動作チェックの総まとめが「単体テスト」や「組み合わせテスト」です。これはコーディングとデバッグが完了した時点で行われるホワイトボックステストで、個々のプログラム（単体）または複数のプログラムから構成されるシステム（組み合わせ）が製作者の意図通りに動作することをチェックするものです。

さて、SE やプログラマなら、ほとんどの人がここまでは経験したことがあるでしょう。しかしもうひとつ重要なテストが残っています。