ソフトウエア開発では、出来上がった成果物の動作を確認するためにテストを実施する。ところが、このとき作成する「バグ票」(不具合チケットとも呼ばれる)の書き方が悪く、開発現場が逆に混乱するケースが少なくない。「どういう意味か」「手順が分からない」「そのときの環境は?」など、疑問点が多く、修正が前に進まないのだ。

 バグ票は、テストで発見した不具合の情報を記述した個票である。最近はBTS(バグトラッキングシステム)を使ってチケットとして管理するのが一般的だが、Excelなどで管理する場合もまだある。いずれにしても、開発現場ではこのバグ票をベースに、開発担当とテスト担当が連携してバグを修正していくことになる。

 バグ票にまつわるトラブルを経験した読者も多いだろう。実のところ、現在はテスト専業ベンダーに勤務する筆者も、過去にはそうした苦い経験がある。今回から始まる本連載では、現場でよくある「駄目なテスト」の回避策を紹介する。第1回の今回はこの「バグ票」について取り上げよう。

ソフトウエア品質を左右するバグ票

 一見地味なバグ票は、ソフトウエアの品質を左右するとても重要な存在だ。バグ票の書き方ひとつで、開発担当とテスト担当のコミュニケーションが円滑になり、プロジェクト全体の生産性が向上する。ソフトウエアの品質向上にもつながるものだ。

 テスト担当の仕事を「バグを見つけて報告すること」と考えてテストを実行すると、駄目なバグ票を生みやすい。なぜなら本当に重要なのは「品質を高める改修につなげること」だからだ。この視点はしばしば抜け落ちる。

 品質を高める改修につなげるという視点が抜け落ちると、一方的なコミュニケーションとなる。テスト担当は伝えたつもりでも、開発担当には必要な情報が伝わっていない。テストの実行に慣れてくると、スピードを重視したくなる。その結果、コミュニケーションがおざなりになるのが、ありがちなパターンだ。

 駄目なバグ票が作られると、開発担当とテスト担当の間で追加のやり取りが必要になる。また、バグの再現確認に掛かる工数が大きくなる。意図しない改修や不十分な改修が発生することもある。

 では、どんなバグ票が理想的なのか。以下では、テスト担当から開発担当に情報が確実に伝わるバグ票の書き方を説明しよう。