バグの報告者もユーザである

バグの報告者もユーザである

紙やExcelでのバグ票のテンプレートや、BTSのバグ登録画面を作る場合に、当然のことながらバグ報告時に記入する項目を決めることにな る。この際に、どんな項目の記入を必須とするか、また任意で記入できる項目はどのようなものを設定するのかについて、十分検討する必要がある。ここで検討 を怠ってしまうと、実際にバグ管理の運用がはじまってから、「この項目がない」「必須入力の項目に記入が漏れている」など、バグ管理の運営に支障がでるか らだ。

またバグ票のインターフェースもしっかりと検討するのがポイントである。報告者がなるべく入力が容易で、必要な情報がしっかりと記入できるものであれば、漏れなくバグの収集ができ、効率のよいバグ管理が実現できる。

必須入力の項目は枠線を太くすることがあげられる。また、選択肢のある項目はあらかじめ選択内容を記述しておき、チェックを付けるだけでよい状態にしておく。例えば、テスト対象のWebブラウザの種類やバージョンをバグ票にあらかじめ記載しておくのである。

バグ票作成の注意

自分がバグ報告者の立場に立って、どのような環境を用意すれば快適に使ってもらえるかを常に考えておこう。

ツールの管理者を1人にしない

BTSの管理を1人が担当していると、その管理者の突然の不在（異動・辞職・ケガ・病気など）の際に、バグ管理の要であるシステムを管理できる人材がいなくなってしまう。辞職や異動であれば引き継ぎの時間を作ることも可能だが、ケガや病気のような場合は引き継ぎが難しい。

ツールを使い込んでいくと、カスタムクエリを作成したり、独自の拡張を施したりとプロジェクトで使いやすいようにチューニングされていることが多い。普段からその内容を知っておかなければ、いざというときに困ることになる。

プロジェクトでBTSなどのツールを利用している場合は、そのようなリスクも意識しておくべきだ。またツールの管理者は、積極的にその運用ノウハウをプロジェクトメンバーへ展開しておくべきである。

チームメンバ間での情報共有を行う

プロジェクトの規模が大きくなると、他のメンバーが何をしているのかということに無関心になりがちである。お互いの作業内容のことを知らない と、同じ原因のバグ修正に着手していたり、異なるバグの修正でもソースの同じ箇所に手を加える可能性も高く、作業の無駄が多く発生することがある。

朝会や夕会、あるいは互いのタスクリストの共有（メールやBTSなどを利用）を行い、メンバー間の情報を共有し、無駄な作業を極力減らすようにしよう。これはバグ管理に限った話ではないが、効率のよいバグ管理を行う上でも重要なことなので、あえてあげることにした。

最後に

近年、要求されるアプリケーションの機能が高度化し、同様に品質も求められるようになっている。適切にバグを管理し修正していくことは、アプリ ケーションの品質を高め、ユーザの信頼を勝ち取ることにつながっていく。本連載が少しでもその手助けになることができれば幸いである。