開発者が迷わない不具合起票の方法とは？修正までのワークフローも解説
システム開発で不具合が発生した際は、発生状況などを整理するために起票が必要です。
このとき、必要な情報を正確に記録しないと、後で「再現できない」「修正確認ができない」などのトラブルにつながる恐れがあります。
また、修正者がテスト実施者に状況をわざわざ聞かなければいけない、など、工数がかかる恐れもあります。
この記事では、テスト担当者が不具合起票の際に迷わないように、具体的な書き方を紹介します。また、不具合の修正と確認のワークフローについても解説するので、ぜひ参考にしてください。
不具合起票の目的と役割
テストで検出されたバグを記録・管理するためのドキュメントを「不具合票」といいます。不具合の内容や発生状況、再現手順などを詳しく記載し、開発者による原因調査や修正後の動作確認などの際に参照するものです。
システム開発では、いくら仕様書通りに開発・設計を進めても、想定外の動作は発生するものです。不具合票は、テスト担当者から開発チームへの修正依頼や、原因調査などをスムーズに進めるためにも重要な役割を果たします。
不具合報告に必要な項目
不具合票は、テスト担当者以外の人でも内容を理解できるように、具体的に記入しましょう。ここでは、不具合票に書くべき項目を解説します。
タイトル（概要）
不具合票のタイトルは、短くするよりも、発生した現象を具体的に想像できるように書くのがお勧めです。「いつ」「どこで」「何をして」「どうなった」を意識すれば、一目で分かるタイトルにしやすいでしょう。このとき、機能の名称を統一しておくと、起票済みの不具合を検索する際に役立ちます。
重要度／優先度
修正の優先度は、不具合の内容で決まります。たとえば、システムダウンにつながる不具合は重要な問題のため、できる限り早期に解決したいでしょう。一方、単なる誤字なら、修正は後回しでも問題ないかもしれません。また、「この機能が動かないと、それに関連している機能のテストができない」という問題がある場合は、早く修正を行わないとテスト計画自体の遅れを招きます。このような不具合が他のテストの実施を妨げているような状態を「ブロッキング」といいます。テスト担当者はテスト計画が予定通り実施できるかどうか確認が必要です。テスト担当者が不具合ごとの重要度を設定しておけば、開発者は修正の優先度を判断しやすくなります。
再現手順
テスト担当者でなくても不具合を再現できるように、操作の順序やタイミングを詳しく記載します。明確かつ端的に記述することで、開発者が不具合の原因を特定しやすくなります。必ず再現するとは限らない不具合については、発生確率も記録しておきましょう。
期待値と実際の結果
不具合票には、「本来ならどうなるべきか」と「実際にはどうなったか」を記録しましょう。この情報がなければ、開発者は何が期待と異なっているのか分かりません。テスト担当者が開発者に「このような点が正しくないと思う」と伝えることで、開発者は原因の調査をスムーズに開始できます。期待値と実際の結果との差異を明確にすることが大切です。
環境情報
不具合がどのような環境で発生したのかも、重要な情報です。OS・バージョン・設定の他、テストに使用したデバイスやデータなど、後で不具合を再現する際に必要な情報を記録します。これにより、特定のデバイスやデータのみで問題が発生するケースでも、原因調査を進めやすくなるでしょう。
スクリーンショット・ログ
不具合に関連するスクリーンショットやログを取得できた場合は、不具合票とセットにして保存しておきましょう。スクリーンショットがあれば、テキストのみでは説明しづらい表示上の不具合やエラーメッセージなどについて視覚的に伝えられます。ログがあれば、不具合の発生タイミングや対応するソースコードを素早く特定して、調査の工数を削減できる可能性があります。
不具合の修正方針・範囲の確認
不具合が発見された際は、どのような方針で修正すべきかを検討する必要があります。根本的な原因を特定して修正するのが理想ですが、納期が迫っていて十分な時間を確保できないために、対症療法による応急的な対応のみでリリースしなければならない場合もあります。ソフトウェアアップデートが可能な機器であれば、根本的な原因を解決をしたソフトウェアを後々リリースすることで対応することもできますが、アップデートが不可能な機器である場合、このような対処療法による対応が難しいかもしれません。特に組み込みソフトウェアではアップデートが簡単にはできない機器や、できない状況に置かれる機器が少なくありません。こういった不具合が開発の最終段階で見つかるようなことが無いようにテスト計画を立てる必要があります。
また、修正方針を検討する際は、修正の影響範囲を確認することも重要です。デグレード（修正作業により別の問題が発生してしまうこと）を起こさないために、開発者はプログラムの修正箇所に関連する機能を洗い出し、実際に修正する前に影響範囲を特定する必要があります。
不具合管理のワークフロー
不具合は、明確なワークフローで管理することが大切です。一般的には、開発チームと協力して「起票」→「原因調査」→「修正」→「リテスト」の流れで作業を進めます。
不具合票には、「未着手」「対応中」「修正済み」「クローズ」などのステータスを設定しましょう。ステータスがあれば、プロジェクトの全員が不具合対応の進捗状況をいつでも把握できます。
また、定期的に不具合の一覧表をレビューすることも大切です。対応漏れを防いだり、優先度を見直したりして、プロジェクト全体のスケジュールへの影響を抑えましょう。
まとめ
不具合票には、不具合の原因調査や修正に必要となる情報を正確に記載することが大切です。明確なワークフローで不具合を管理すれば、テスト担当者と開発者との連携がスムーズになります。また、不具合を修正する際には、事前に修正方針や影響範囲を確認することも重要です。限られた工数の中でも着実に品質を高められるよう、しっかりとした不具合管理の体制を整えましょう。