はじめに
こんにちは、株式会社ビットキーでSoftware QAチームに所属しております要と申します。
普段はworkhubという、働く人と空間においてあらゆるものをコネクトし、それぞれの働き方に即した体験を提供することができるプラットフォームのQAを行っています。
workhubに関してはこちらのページをご覧ください。
今回はQA業務において欠かすことのできない「不具合起票レポート」について、私自身がいつも心掛けていることを書こうと思います。
不具合起票レポートとは、システムや製品に関する問題や不具合が発生した際に、その詳細を記録し報告する文書のことです。事象の内容、発生状況、再現手順などを記載し、修正や対応のための情報を提供します。
"インシデントレポート""バグレポート""障害報告書"など様々な呼び方がありますが、この記事では不具合起票レポートと統一させていただきます。
また本記事では「仕様通りではあるが改善を希望する」という要望の起票レポートについては言及しておりません。
2023年からテストの分析〜設計を行うようになりましたが、不具合起票レポートに関しては2020年から続けておりもうすぐで5年になります。エンターテインメント業界から現在のIT業界へ、業種こそ変わりましたがかれこれ5年間も不具合と向き合い、事象をまとめ、開発者宛へ報告を行なっています。
そんな私がこれまで先駆者から教えていただいたこと、学んだこと、独自で「こうした方が伝わりやすい」と思った点を、王道から細かい点まで心掛けていることや改善ポイントをご紹介します。
不具合起票レポートなんて早くてナンボ！そう思われる方も改めて記載の仕方を意識することで、読み手にとって解りやすく問題を解決しやすいレポートに仕上げることが出来るかもしれません。
不具合起票レポートの構成
記載順は前後しますが、不具合起票レポートの一般的な構成は概ね下記の通りかと思います。
1.タイトル（要約）
2.発生事象内容
3.再現手順
4.環境情報
5.期待値
6.発生事象のキャプチャやクリップ
7.不具合の重要度
8.その他の情報
上記の構成に沿って、基本的な記載内容と、記載する際に心掛けていることや改善ポイントをご紹介していきます。
タイトル（要約）
不具合起票レポートを読む際にまず目にするのはタイトルです。そのレポートがどんな内容であるかを一目で解るようにするため、タイトルは事象内容の要約である必要があります。
私の場合、下記に当てはめて考えると簡潔にまとまります。
「いつ」「どこで」「何をして」の順は文章により前後しますが、「どうなった」で締めることで条件はともあれ結果的にどうなってしまったのかが明確になります。
細かい条件や手順がある場合はどうしても長文になってしまったり、複雑になってしまう場合もありますが、そのような時は「特定の条件で」のような形で記載し、レポート本文に詳細を記載します。
しかし基本的には、レポートの本文を読まなくても事象内容が解ることを目指しています。
また、タイトルは過去に起票された既存不具合を検索する際に重要であると考えています。画面名などの名称や表現を統一し、解りやすいタイトルをつけることが大切です。
発生事象内容
発生事象内容も、「いつ」「どこで」「何をして」「どうなった」をベースにして、タイトルよりも詳細に、正確に事象内容を記載します。
また、同じ手順でも挙動が異なるものについては、以下のような表にまとめることでよりわかりやすく整理することができます。
補足情報も記載しておくと丁寧です。
補足情報には、例えば「本番環境では再現したか」、「潜在の不具合なのか、新規機能追加に伴う不具合なのか」や、起票までに開発者とのやりとりがあった流れで不具合起票となった場合、担当者が誰になっても状況を理解してもらうため経緯を載せられるようであればその旨を一文添えて、やりとりのあったリンク先を記載しています。
再現手順
再現手順は、不具合事象に繋がるまでの一番最短の手順を記載するようにしています。
極端ですが、開発者ではない何もわからない状態の方でも、その手順を踏めば不具合事象に遭遇するよう簡潔に、明確に記載することを目指しています。
前提条件は手順より前に配置し、その後に手順を３ステップ程度に収めることを意識しあまり長く複雑にならないようにしています。
環境情報
手順と続けて、環境情報を記載します。不具合事象の再現確認をしてもらうため、確認できる実際のデータ・アカウント・パスワードなどを記載しておきます。
開発者から「これを見るための⚪︎⚪︎の情報ください！」というやりとりをなくすためにも必要な情報を書き漏らさないようにします。
初めはどんな情報を記載すべきか解らなくても、プロダクトの知識が深まることで必要だと思われる情報は自ずと身についていくと思います。
期待値
不具合起票レポートにおける期待値が、本質を捉えているかどうかで、不具合の対応や修正がスムーズに進むかが大きく異なります。
以下に、期待値の記載が本質を捉えている例と、捉えていない例をそれぞれ挙げます。
本質を捉えていない例の方は、具体的に何が正しく表示されるべきか、つまり合計金額が更新されないことに言及していないため問題の本質を伝えられていません。これでは、開発者が正確な問題を理解するのに時間がかかってしまう可能性があります。
本質を捉えている例の方は、システムの具体的な正常動作と合計金額が更新されないという問題の本質が明確に示されているため、開発者が不具合の原因と解決方法を迅速に理解できます。
期待値は、システムの正しい動作を具体的に示すことが重要で、そうすることで開発者が正確に問題を把握し、解決に向けたステップをスムーズに進めることができます。
発生事象のキャプチャやクリップ
テキストのみでは説明しづらいUIのレイアウトや表示されるエラーメッセージなどは、キャプチャやクリップなどを添付することで具体的にどのような不具合が発生しているかを視覚的に伝えることができます。
動画(クリップ)は不具合が発生する手順や状況を詳細に記録するために有効です。これにより開発者が起票者と同じ手順を再現しやすくなり、不具合の原因特定がスムーズになります。
またスクリーンショット(キャプチャ)などを載せる際は、画面のどこに不具合があるのかがわかるように、枠や矢印などで指し示す編集を施してから載せると伝わりやすくなります。
不具合の重要度
重要度を記載することで、不具合の修正や対応優先順位が明確になります。開発者は緊急度の高い不具合から修正に取り組むことができ、リソースを効率的に配分できます。
そのため不具合の重要度は主観的な感覚で決めるのではなく、できるだけ客観的な基準に基づいて判断することが大切です。
その他の情報
不具合起票レポートには、不具合の詳細だけでなく、検証期間中に必要な情報も記載します。
例えば、起票者、検証対象バージョン、進捗ステータスなどです。これらはタグの選択など、様々な方法で管理できますが、重要なのは入力漏れがないようにすることです。
レポートの内容が完璧でも、検証対象バージョンの選択を忘れたことにより開発者が問題に気づくのが遅れてしまう可能性もあります。
こうした点は忘れがちなので、最終的にしっかりと確認することが大切です。
まとめ
以上までをまとめると、効果的な不具合起票レポートを作成するポイントは下記の通りです！
タイトルで要約する
「いつ」「どこで」「何をして」「どうなった」を意識し、簡潔でわかりやすいタイトルをつけることで、読み手がすぐに内容を把握できるようにする。
発生事象を正確に記述する
事象内容を詳細に記述するだけでなく、表や補足情報を活用することで、より理解しやすくする。
再現手順を明確にする
誰でも再現できることを意識して、簡潔で明確な手順を記載する。
環境情報を漏れなく記載する
再現に必要なデータは手戻りを防ぐためにも、漏れなく記載する。
期待値を本質的に捉える
システムの正常な動作を具体的に示すことで、開発者が問題の本質を理解しやすくする。
視覚的な情報を活用する
キャプチャやクリップなどを活用し、不具合の状況を視覚的に伝える。
重要度を客観的に判断する
緊急度に基づいて重要度を設定することで、開発者が優先順位を判断しやすくする。
その他の情報も漏れなく記載する
検証対象バージョンや進捗ステータスなど、必要な情報を漏れなく記載することで、円滑な修正作業を促進する。
おわりに
以上が、私が普段不具合起票レポートを作成する際に心掛けていることです。
不具合起票レポートは単なる報告書ではなく、より良いプロダクトを創り上げるための「開発者との連携を深めるためのツール」と思いながら作成しています。
「正確に」「簡潔に」「わかりやすく」を意識し、開発者にとって理解しやすいレポートを作成することで、スムーズな問題解決に繋がり、ひいてはユーザーに質の高いサービスを提供することに繋がります。
この記事が不具合起票レポート作成のガイドとなり、より快適に仕事を進めるためのお役に立てれば幸いです。
Discussion