やさしいバグトラッキング
From The Joel on Software Translation Project
Joel Spolsky ジョエル・スポルスキ
翻訳: Yasushi Aoki 青木靖
2000/11/8
TRS-80 Level-I BASICはたった2つの文字列変数A$とB$しか格納できなかった。同様に、私は頭にたった2つのバグ格納スロットしか持たずに生まれてきたらしい。あなたが3番目を覚えさせようとしたら、1つは床に落っこちて綿ゴミと一緒にベッドの下に掃き込まれてしまうだろう。
バグデータベースを使っていることは優れたソフトウェアチームの目印になる。実際にそれをやっているチームがいかに少ないかということには、いつも驚かされる。大きな間違いの1つは、プログラマがすべてのバグを覚えておけるとか、あるいはポストイットで管理できると信じていることだ。
しばらくあなたの耳を拝借できるなら、以前のアーティクル「やさしいスケジュール」と「やさしい機能仕様」の精神にのっとり、バグトラッキングのとても簡単なやり方について説明しよう。
何よりまず、本当のデータベースが必要だ。長い週末にちょっとしたコードを書いている2人のチームなら、たぶんテキストファイルでもデータベース替わりになるだろう。しかしそれよりも大きいプロジェクトでは、本当のバグトラッキングデータベースが必要になる。あなたの手に入るバグトラッキングデータベースはたくさんある。(あからさまな自己宣伝をすると、私たちがFog Creek Softwareで作ったFogBUGZという製品は、Webベースでとても使いやすく、非常に強力だ。自分でそう言って構わないなら。)
説明のため、ひとつのバグが誕生してから誰かがついにそれを苦難から救い出すまでの過程を見てみよう。私たちが追跡するのは有名なBug 1203だ。以下はこのバグに関するバグデータベースの内容だ。
| ID | 1203 | |
| Project | Bee Flogger 2.0 | |
| Area | FTPクライアント | |
| Title | ファイルアップロード時にFTPサーバがコアを吐く | |
| Assigned To | 完了 | |
| Status | 完了：解決(修正済み) | |
| Priority | 2 - 修正要 | |
| Fix For | 2.0 Alpha | |
| Version | Build 2019 | |
| Computer | ジルのiMac、Mac OS 9.0、128M RAM、1024x768 色数最高 | |
| Description |
公開 by それはそれは優秀なテスタのジル 2000/11/1
開発主任ウィリーに割り当て by それはそれは優秀なテスタのジル 2000/11/1 解決(修正しない) by 開発主任ウィリー 2000/11/2 (昨日) こっちのコードじゃないよ、ジル。Linuxのproftpdの問題だね。 再開 (開発主任ウィリーに割り当て) by それはそれは優秀なテスタのジル 2000/11/2 (昨日) そうは思いません。普通のftpクライアントで接続してproftpdをクラッシュさせられるなんて聞いたことありません。私たちのコードだと毎回クラッシュします。ftpサーバは何でもないのにクラッシュしたりはしません。 プログラマのミッキーに割り当て by 開発主任ウィリー 2000/11/3 (今日) ミッキー、見てもらえるかな？君のクライアントコードが何か悪さしてるかもしれない。 解決(修正済み) by プログラマのミッキー 2000/11/3 (今日) どうもパスワードか何かのかわりにユーザ名を渡してたみたい･･･ 再開(プログラマのミッキーに割り当て) by それはそれは優秀なテスタのジル 2000/11/3 (今日) Build 2021でも起きるんですけど。 編集 by プログラマのミッキー 2000/11/3 (今日) うげっ、変だな。デバッグしてみます。 編集 by プログラマのミッキー 2000/11/3 (今日) MikeyStrCpy()のせいみたい･･･ 解決(修正済み) by プログラマのミッキー 2000/11/3 (今日) やったー！ 完了 by それはそれは優秀なテスタのジル 2000/11/3 (今日) build 2022で直っているみたいです。完了します。
|
起きたのはこういうことだ。
プログラマのミッキーは彼のいかしたMacintoshソフトの新しいFTPクライアント機能をハックしていた。ある時点でいい気になった彼は、自分のオリジナルバージョンの文字列コピー関数を書いた。うるさい再利用ポリスよ見るがいい！ガッハッハ！
コードを再利用しないとまずいことが起きるんだよ、ミッキー。そして今日起こったまずいことは、ミッキーがコピーした文字列をゼロ終端し忘れたと言うことだ。彼がそれに気づかなかったのは、たまたま文字列をあらかじめ0で初期化されたバッファにコピーしていたからだ。
その週の後半に、それはそれは優秀なテスタのジルが額をキーボードの上で前へ後ろへと動かしながら、そのコードをガンガンたたき、言い換えれば過酷なテストをした。(ちなみにいいテスタの多くは名前がジルか、あるいはジリアンみたいなそのバリエーションになっている)。突然とても奇妙なことが起こった：彼女がテストに使っていたftpデーモンがクラッシュしたのだ。そう、それはLinuxマシンだったし、Linuxマシンが決してクラッシュしないというのは知ってるけど(slashdotの人たち、どうか騒がないで)、そいつはクラッシュしてしまったのだ。そして彼女はサーバには触りさえせず、ただミッキーのMacプログラムでファイルをFTPしただけだった。
さて、ジルはそれはそれは優秀なテスタで、自分がしていることを注意深く記録していた(たとえばキーボードの上で彼女が頭を動かすとき、その正確なピッチとヨーは、彼女の実験ノートに書き込まれているのだ)。彼女がすべて再起動し、きれいな状態でその手順を繰り返してみると、何ということか、再び起きたのだ！Linuxのftpデーモンが再びクラッシュしたのだ！これで1日に2回だ！聞いたかい、リーナス。
ジルは目を細めて再現手順のリストを見ていた。それは20ステップほどだった。そのいくつかは関係なさそうだった。いくつか実験して、ジルは問題の所在を4ステップにまで絞り込むことができた。さて彼女はバグレポートを提出する準備ができた。
ジルは新しいバグレポートをバグトラッキングデータベースに入力した。ところで、ただバグレポートを入力するのにも規律が必要だ。良いバグレポートと悪いバグレポートというものがあるのだ。
[edit] 良いバグレポートが持っている3つのもの
そして主の語りて曰く、｢最初に汝が聖なるピンを取りはずせ。それから3まで数えよ、それより多くても少なくてもいかん。3が汝が数うべき数で、数うる数は3でなくてはならん。4は数えてはならず、次に3へ進むのでなくば2を数えてもならん。5は即刻。ひとたび第3の数なる3に至らば、汝のアンティオキアの聖なる手投げ弾を汝が敵に向かいて投げつけよ、我が目に下品なる敵はくたばらん｣--モンティ・パイソン・アンド・ホーリー・グレイル
良いバグレポートのルールを覚えるのは簡単だ。すべての良いバグレポートに必要なものは正確に3つだ。
- 再現する手順、
- 期待されること、そして
- その代わりに観察されたこと。
簡単そうでしょう、どう？そうでもないかもしれない。みんないつも取り除けておいたバグを1つか2つ、プログラマの私に割り当てる。
もしあなたがバグの再現手順を言わなかったなら、私はあなたが何の話をしているのか分からないだろう。「プログラムがクラッシュして机に臭い糞みたいなものを残すんだ」。素敵だね、ハニー。君が何をやっていたのか教えてくれなかったら、私には何もできない。しかし、正確な再現手順を得るのが難しい2つのケースがあるのも確かだ。あなたは単に覚えていなかったり、ただ「現場」からのバグレポートを記録しているだけかもしれない。(しかし何でみんな「現場」(field)って呼ぶんだろう？ライ麦畑(field of rye)か何かみたいなもの？まあ何でもいいけど・・・) 再現手順がなくてもいいもう1つの場合は、バグが時々起きるが、いつも起きるとは限らないという場合だ。しかしその場合でも、再現手順を、それがそうたびたび起こるわけではないと言う注釈つきで書いておくべきだ。そのようなケースではバグを見つけるのはとても難しくなるが、それでも試みることはできる。
あなたが期待されることが何か示さなかったなら、何でそれがバグなのか私は理解できないかもしれない。スプラッシュスクリーンに血がついていた？だったら何？それを書いてたときに指を切ったんだ。何を期待してたの？ああ、仕様では血は出てこないことになってるって言ってるんだ！それで君がなぜバグだと思っているのかが分かったよ。
3番目は、代わりに何を見たか。あなたがそれを教えてくれなかったなら、私にはバグが何なのか分からない。これはすぐ分かることだと思う。
[edit] 話に戻ろう
いずれにしても、ジルはバグレポートを入力した。いいバグトラッキングシステムは、それを自動的にプロジェクトの開発主任に割り当てる。これが2つ目のアイディアだ。どのバグレポートもそれが完了するまで、常にちょうど一人の人間に割り当てられていなければならない。バグレポートはホットポテト(厄介な問題)みたいなもので、それが割り当てられたとき、あなたはどうにかしてそれを解決するか、あるいは誰か別な人に割り当ててやる責任がある。
ウィリーは開発主任で、バグレポートを見て、それがたぶんftpサーバのせいだと判断し、それを「修正しない」として片付ける。なんと言ってもftpサーバを書いたのは彼らじゃないのだ。
解決されたバグレポートは、それを公開した人に割り当て直される。これが重要な点だ。バグレポートはプログラマが片付いたと思っただけでは片付かないのだ。黄金律はバグレポートを完了できるのはそれを公開した人だけだということだ。プログラマはバグレポートを「一丁あがり」と言って解決することはできるが、しかし実際にバグレポートを完了させ、リストからはずすためには、それを公開した人が実際にフィックスされたことを確認するか、あるいはそれが何かの理由で直す必要がないということに同意する必要がある。
ジルはバグレポートが彼女のコートに打ち返されたことを告げるemailを受け取る。彼女はそれを見て、開発主任ウィリーのコメントを読む。どうも正しくなさそうだ。みんなそのftpサーバを何年も使っていたがクラッシュしたことはない。それがクラッシュするのはミッキーのコードを使ったときだけだ。それでジルはバグレポートを再開して彼女の考えを説明し、バグレポートはウィリーに送り返される。今度はウィリーはバグを修正するようにミッキーに割り当てる。
ミッキーはバグを調べ、長い間熱心に考え、そして完全な誤診をする。彼は全然違うバグを修正し、ジルが公開したバグレポートを解決する。
バグレポートはジルに戻され、今回は「解決-修正済み」とマークされている。ジルが最新のビルドで再現手順を実行すると、何ということか、Linuxサーバがクラッシュするのだ。彼女はバグレポートを再び再開し、直接ミッキーに割り当てる。
ミッキーはまごつくが、最後にはバグの原因を突き止める。(まだ分からない？これは読者の練習問題に残しておく。十分なヒントは与えたはずだよ！) 彼はそれをフィックスし、テストし、そして--やった！再現手順はもはやftpサーバをクラッシュさせない。もう一度彼は「修正済み」としてバグレポートを解決する。ジルもまた再現ステップを実行し、バグがちゃんと修正されているのを見て、それを完了させる。
[edit] バグトラッキングのための10のヒント
- 良いテスタは再現手順を最小限のステップに絞込む。これはバグを見つけなければならないプログラマにとても助けとなる。
- バグレポートを完了できるのはそれを公開した人だけだというのを覚えておくこと。誰でもそれを解決はできるかもしれないが、見つけたバグがフィックスされたと本当に確認できるのは、それをはじめに見つけた人だけだ。
- バグを解決する方法はたくさんある。FogBUGZはバグを修正済み(fixed)、修正しない(won't fix)、延期(postponed)、再現せず(not repro)、重複したエントリ(duplicate)、仕様(by design)に分類できる。
- 「再現せず」は誰もそのバグを再現できないことを意味する。バグレポートに再現手順がない場合にプログラマはしばしばこれを使う。
- あなたは注意深くバージョンを管理しておきたいと思うだろう。テスタに渡すソフトウェアのビルドにはそれぞれビルドIDをつけておくべきで、哀れなテスタがバグをフィックスしていないバージョンでバグのテストをするようなことがないようにする。
- あなたがプログラマで、テスタにバグデータベースを使ってもえらずに困っているのなら、他の手段によるバグレポートの受け取りを拒めばよい。テスタがバグレポートをemailで送ってよこすなら、「emailを整理しきれないのでバグデータベースのほうに入れてください」という簡単なメッセージとともに送り返せばよい。
- あなたがテスタで、プログラマにバグデータベースを使わせることができないなら、バグについて直接彼らに教えないで、それをバグデータベースに入れ、バグデータベースからemailで通知が行くようにすればよい。
- あなたがプログラマで、ほんの一部の同僚しかバグデータベースを使っていないなら、ただデータベースのバグレポートを彼らに割り当て始めればよい。彼らもいつかはヒントに気づくだろう。
- あなたがマネージャで、あなたが大枚はたいてインストールしたバグデータベースを誰も使っていないようなら、新機能の開発をバグレポートを使って割り当てればよい。バグデータベースは優れた「未実装機能」データベースでもあるのだ。
- バグデータベースに新しいフィールドを追加するという誘惑を排除すること。毎月、誰かがデータベースに入れる新しいフィールドのアイディアを考え出すだろう。たとえばバグが見つかったファイルを記録するとか、バグが何%の確率で再現するかとか、バグが何回起こったかとか、正確にどのバージョンのどのDLLがバグの起きたマシンにインストールされているかといった、あらゆる種類の気の利いたアイディアを得るだろう。重要なのはこれらのアイディアを聞き入れないということだ。もしそれをやると、あなたの新しいバグレポート入力画面は、設定しなければならない何千ものフィールドでいっぱいになり、もはや誰もバグレポートを入力したがらなくなるだろう。バグデータベースが機能するためには、誰でもそれを使える必要があり、もし公式にバグレポートを入力するのに手間がかかりすぎるなら、みんなバグデータベースを避けるようになる。
もしあなたがチームであれ単独であれコードを開発しており、コードの中の既知のバグをすべてリストアップした組織化されたデータベースを持っていないのなら、単に低品質のコードを出荷することになるだろう。良いソフトウェアチームでは、バグデータベースは広く使われているというだけでなく、人々はバグデータベースをto-doリストとして使うようになり、そして彼らはWebブラウザのデフォルトページを彼らに割り当てられたバグレポートのリストに設定する。そして彼らはマウンテンデューをもっとストックして置くようにというバグレポートを、オフィスマネージャに割り当てたいと思うようになる。
この記事の原文（英語）は Painless Bug Trackingです。
