良いバグレポート

プログラムを開発すれば、もれなくテストがついてきます。人間が書いたプログラムであればどんなプログラムでもテストをすると大なり小なり必ずバグが見つかります。複数人で開発を行うときには、バグの内容を開発した本人に伝える必要があるわけですが、意外にこれが難しかったりするわけです。

Joel on Software - やさしいバグトラッキング

良いバグレポートのルールを覚えるのは簡単だ。
すべての良いバグレポートに必要なものは正確に3つだ。
１．再現する手順、
２．期待されること、そして
３．その代わりに観察されたこと。

そのテの本を読むと難しいことがたくさん書いてあったりしますが、これはわかりやすいし、何より的を射ていますね。

† はじめに必要なのは「期待されること」

ここでの真のポイントは「期待されること」がなくてはいけないことなんだろうと思います。当たり前のことですが、正しいかどうかを検証するには、何が正しいかということが決まっていないと差異が検出できないということです。

† 大学ではテストは軽視されている

最近は自分でもそれが当たり前と思えるようになりましたが、自分自身が大学生の時にはやはりこの意味がぜんぜんわかりませんでした。大学の先生になるような方々でSEやPGの経験がある人がほとんどいないので、これはまぁ仕方がないということなのかもしれませんが、悲しいことに大学ではテストは非常に軽視されています。

自分の研究チームだけでもこのような状況を何とかしなければと思って、来期はテストのやり方を変えようと今から画策しています。

† で、大学でのプログラム開発の現状

大学に通っているので、普通の大学生のプログラム開発を見る機会も多いのですが、彼らのプログラミングのパターンはこんな感じです。

１．期待されること（＝仕様なわけですが）を何も決めずにいきなりプログラムを書き始める。

２．プログラムが完成したと言う。

３．テストをすると言って、プログラムを起動して何かに取り付かれたようにしばらくプログラムを動かす。

４．バグが見つかったと言って、一心不乱にプログラムを修正。

以下、２～４の繰り返し。

こんな作業がいかに意味がないかってことすらわからない人が情報工学を修めたと卒業していくのですから本当にかわいそうです。