小さい頃はエラ呼吸

いつのまにやら肺で呼吸をしています。


優れたバグ管理を行うための10のヒント(後編)


photo credit: massdistraction via photopin cc

はじめに

10年以上前の記事だけど、バグ管理について書かれたとても良い記事を見つけました。ぼくなりにJoel on Softwareの「やさしいバグトラッキング」を解釈してまとめてみました。

前編はこちら。

実践バグ管理―プロジェクトを成功に導くための
クジラ飛行机 あかさた
ソシム
売り上げランキング: 595,221

優れたバグ管理を行うための10のヒント

6.バグの報告はBTS(バグ管理システム)経由で行う

あなたがプログラマで、テスタにバグデータベースを使ってもえらずに困っているのなら、他の手段によるバグレポートの受け取りを拒めばよい。テスタがバグレポートをemailで送ってよこすなら、「emailを整理しきれないのでバグデータベースのほうに入れてください」という簡単なメッセージとともに送り返せばよい。

こんなバグがありましたよと、プログラマに対して口頭や個別のメールでバグの報告しないこと。バグの報告はBTS経由で行うことで関係者全員に周知されることが望ましいです。
口頭でバグ報告を受けてもうっかり忘れてしまうことがあります。メールでの報告もメールを見逃したら意味がありません。BTSに登録しておけば管理者がステータスを管理してくれるので、修正されていないバグがあればすぐに気づくことができます。

7.プロジェクト全体でBTSを運用する

あなたがテスタで、プログラマにバグデータベースを使わせることができないなら、バグについて直接彼らに教えないで、それをバグデータベースに入れ、バグデータベースからemailで通知が行くようにすればよい。

一部の人だけがBTSを使うのではなく、プログラマもテスタも全員でBTSを運用していくことが重要です。
大きなシステムでは、開発チームとテストチームが別れている場合があります。テストをしていて不具合が見つかっても、テストチームは開発チームの誰が作ったのかを知る由がありません。
BTSに登録しておけば、おのずと作成者の元へバグ票がアサインされるはずです。

8.BTSの良さに気づかせる

あなたがプログラマで、ほんの一部の同僚しかバグデータベースを使っていないなら、ただデータベースのバグレポートを彼らに割り当て始めればよい。彼らもいつかはヒントに気づくだろう。

バグ管理の手段としてBTSを採用するなら、プログラマの人たちへBTSの使い方や利点についてレクチャします。
世の中にはたくさんのBTSがあり、プロジェクトの種類も千差万別です。運用してみてダメなら他の手段を検討する必要がありますが、少なくともExcel一覧表によるバグ管理よりは優れていることを伝えましょう。

9.BTSをタスク管理システムとして使う

あなたがマネージャで、あなたが大枚はたいてインストールしたバグデータベースを誰も使っていないようなら、新機能の開発をバグレポートを使って割り当てればよい。バグデータベースは優れた「未実装機能」データベースでもあるのだ。

BTSはバグ管理だけでなく、新機能の開発におけるタスク管理システムとしても使うことができます。
まだ実装されていない機能をBTSに登録して、プログラマに割り当てるという使い方からはじめてみましょう。

10.バグに関する入力情報は必要最小限に

バグデータベースに新しいフィールドを追加するという誘惑を排除すること。毎月、誰かがデータベースに入れる新しいフィールドのアイディアを考え出すだろう。たとえばバグが見つかったファイルを記録するとか、バグが何%の確率で再現するかとか、バグが何回起こったかとか、正確にどのバージョンのどのDLL がバグの起きたマシンにインストールされているかといった、あらゆる種類の気の利いたアイディアを得るだろう。重要なのはこれらのアイディアを聞き入れないということだ。もしそれをやると、あなたの新しいバグレポート入力画面は、設定しなければならない何千ものフィールドでいっぱいになり、もはや誰もバグレポートを入力したがらなくなるだろう。バグデータベースが機能するためには、誰でもそれを使える必要があり、もし公式にバグレポートを入力するのに手間がかかりすぎるなら、みんなバグデータベースを避けるようになる。

バグを1件登録するのに、数十の入力フィールドを埋めなければならないシステムはとても使いづらいです。不要な入力フィールドは思い切って削って、登録する情報は必要最低限に抑えましょう。
そのプロジェクトにおいて、必要不可欠だと思われる入力フィールドについては、システムを運用していく中で模索していく必要があります。