42号：デバッグとテスト

≣ 概要

「ASTERセミナー標準テキスト」の14ページについてです。

このページはピンとこない人（意味はわかるけど、何が言いたいのと思う人）が多いです。

「デバッグとテストは、全然違うものだろ。シラバスを読んでも当たり前すぎて、どこが学習のポイントなのか分からない。」というのです。

注意深い人は「シラバスは『テストとデバッグ』となっていますが、ASTERテキストは『デバッグとテスト』と逆順です。何か意図がありますか？」と質問されます。でも、特に意図はありません。図と合わせたらそうなったというだけで言っていることは同じです。

ですから、今回は昔話が中心となってしまいます。「テストの目的」という重い話題が続いたので、今回は気軽に読んでもらえればと思います。

≣ 大昔の話

ソフトウェアが生まれたころは、プログラム開発の一部として、作ったものを完成させることを目的として動かす、いわゆる「動作確認」という行為があっただけで、「テストをする」という意識はなかったのだそうです。

伝聞なのは私が生まれる前（←と書きたかった！？）の話なので、ご容赦ください。

ここで、コーディングしたプログラムが一発で期待通りに動くことはまずありません。普通は、動く以前に、コンパイルが構文エラーなどを出して終わります。（これを「コンパイルが通らない」と言います）
もちろん、なんらかの問題が出たら修正します。
このように、コーディングが終わった後しばらくは、動かしては、バグを取ることが必要でした。正しい用語で書けば、「プログラミングのあとに、欠陥を修正」していました。

これをde・bug（＝バグを取り除く）といいます。英語では「バラなどの植物についた害虫を除く」こともdebug（デバッグ）といいます。

≣ テストの話

小さなソフトウェアを作っているうちは、それで上手くいっていたのですが、プログラムが大きくなると問題が生じてきました。

「自分のコードはデバッグできるけど、他人のコードはデバッグできない」とか「ユーザーのことまで考えていられない」という問題です。

そこで、ソフトウェア開発という仕事から、デバッグの中の「動かして不具合を見つける活動」を切り出して、テストが生まれました。（テスト自体は別のジャンルで、すでにあるプロセスでした）

このようにプロセスとして切り出されることで、「テスト」の技術的専門性についても議論が進むようになりました。1970年代の話です。

≣ 終わりに

以上のことから、現在では、「プログラムを評価すること」をテストと呼びます。（テストについての詳細は、このnoteの「テストの目的」を参照ください）
そして、テストがfailした結果（バグ票によって伝えられることが多い）を開発が受けて、「原因を調べて欠陥を直すこと」をデバッグと呼ぶようになりました。

開発によってデバッグされたソフトウェアについて、同じテストケースを流したり（これを再テスト、あるいは、確認テストと呼びます）、周辺を含めてリグレッションテストを行うのはテスト担当者の役割です。