PR

駄目なバグ票を添削するとこうなる

 次のような良いバグ票を書けると、開発担当に正確かつスムーズに情報が伝わる。

良いバグ票の例
良いバグ票の例
[画像のクリックで拡大表示]

 良いバグ票では、再現手順にログインの状態などの条件や、商品をカートに入れる際のボタン名、カートの遷移元、カートの状態など、バグが発生するまでの手順が詳細に記載されている。

 また、未発生端末を明記している。こうした記載をしておくと、iPhone 5のiOS 10.2のみでバグが発生していると開発担当が理解できる。開発側での再現確認が容易になり、バグ原因の特定にも役立つ。これは意外と忘れられがちだ。発生端末は記載していても、未発生端末まで記載していない現場が多いのではないだろうか。

 そして、発生環境、発生日時の項目を作り、どのテスト環境でいつバグが発生していたのかを記載している。プロジェクトの最中、ソフトウエアは何度も改修される。それに伴い、テスト環境にも手を加えられる。テスト環境に手を加えている最中にテストを実行すると、ソフトウエアが思いもよらない挙動をする場合がある。こうした一時的なバグは同じ手順、同じ端末で何度試みても再現できない。

 再現できない深刻な事象は、プロジェクトを混迷させる原因になる。環境に起因して、一時的に発生しているだけのバグの再現に時間を割かないようにするため、発生環境や日時は必ず記載しよう。

 再現手順が複雑な場合には、画面キャプチャーをバグ票に添付することも正しい情報の伝達には有効だ。

 重要なのは、開発担当がソフトウエアを改修するための、バグを再現させるための情報伝達だ。単に「バグを報告する」のではなく「品質を高める」ためにバグ票を作成すると考えよう。情報不足や行き違いを生みかねない表現を使っていたと感じた場合は、駄目なバグ票と良いバグ票を参考に、読者の現場でも知見を活用してもらえると幸いだ。

■変更履歴
記事掲載当初、本文2ページ目第5段落で「(2)期待値はテスト担当がバグだと判断した根拠となる、正しい仕様を伝えるために」としていましたが、「(2)期待値は正しい仕様を伝え、テスト担当がバグだと判断した根拠となる」です。お詫びして訂正します。本文は修正済みです。 [2017/11/22 19:20]
内藤 義明(ないとう よしあき)
SHIFT
ビジネストランスフォーメーション事業本部 サービス事業部 コアテクノロジービジネスユニット 第1グループ