バグ修正の手順：不具合チケットの担当者になったら
バグの修正担当者になったときに、不具合チケットをどのように活用すればよいでしょうか？ 効率的に不具合修正を進めるために、不具合修正の手順や、チケットに情報が不足していた場合のコミュニケーション方法を学びましょう。
この記事では、不具合チケットを受け取ってから、不具合の再現、修正、再テストの依頼をするまでの流れを解説します。
目次
不具合チケットの対応手順
あなたがもし不具合チケットの修正担当者にアサインされたら、次のような手順で作業を進めましょう：
- 不具合かどうかを判断する
- 不具合を再現させる
- 原因を特定する
- 不具合の修正をする
- テスト実施者に再テストを依頼する
それでは、それぞれの作業について詳しく見ていきましょう。
手順1：不具合かどうかを判断する
不具合チケットが作成されても、そこに記載されている内容が不具合であるとは限りません。 例えば、
- テスト実施時に参照した仕様が間違っている
- 仕様の理解を誤った状態でテストケースを作成してしまった
- テスト実施者の操作に誤りがある
といったケースが考えられます。
不具合の修正を始める前に、チケットの内容を大まかに把握して上記のようなケースに該当するか判断します。 もし該当する場合は、不具合チケットの作成者とコミュニケーションを取りましょう。
手順2：不具合を再現させる
修正作業は、不具合を再現させることから始めます。 「再現させる」とは、テスト実施者が行った操作を修正担当者自身がもう一度実施し、同じ不具合が発生することを確認することです。
不具合を再現できなければ、原因を特定することはできません。 不具合チケットには、不具合の再現手順が記載されているはずですので、 その手順どおりに操作をして同じ不具合が発生するかを確かめましょう。
チケットの再現手順に不明な点がある場合は、記載されている再現手順を実行しても不具合が再現できない場合は、チケット作成者に相談をします。
手順3：原因を特定する
不具合を再現できたら、原因を調べる作業に入ります。 原因を特定するために、不具合に関連するデータをデータベースから検索したりする必要があるかもしれません。 調査に必要な情報が不足している場合は、チケット作成者に問い合わせましょう。
特定できた原因は不具合チケットにまとめます。 この情報は修正後のコードレビューでレビュアーが参照するので、修正対応者ほど不具合に詳しくない人でも理解できるように情報を整理しておきます。
手順4：不具合の修正をする
不具合を修正します。 修正をする前に、修正方針と影響範囲を不具合チケットに書き残しましょう。 修正方針に不安がある場合は、実際にコードを変更する前に、有識者に意見をもらうとよいです。
修正の影響範囲についての情報は、修正後の再テストの範囲を決めるときに必要になります。 例えば、複数の箇所から呼び出されている共通コンポーネントを修正する場合は、再テストの範囲が広くなるといったケースなどが考えられます。 ただコードを変更するのではなく、変更したコードが影響を与える範囲についても考察することが重要です。
手順5：テスト実施者に再テストを依頼する
不具合の修正が完了したら、テスト実施者に再テストを依頼します。 依頼時には、修正の影響範囲とその範囲をテストするための方法をチケットに記載するようにします。
修正したコードがどこから呼び出されているのかをテスト担当者が把握することが難しい場合があります。 そのため、再テストの範囲を決めるのに役立つ情報をチケットに記載すると、テスト担当者が再テストを実施する際に役立ちます。
まとめ
このレクチャーでは、不具合チケットを受け取ってから、不具合の再現、修正、再テストの依頼をするまでの流れを解説しました。 不具合対応の手順は次のとおりです：
- 不具合かどうかを判断する
- 不具合を再現させる
- 原因を特定する
- 不具合の修正をする
- テスト実施者に再テストを依頼する
不具合対応を慌てて進めると、思い込みのせいで真の原因を特定するのに時間がかかったり、修正する必要がなかったのにコードを書き換えてしまうなどの手戻りが発生することがあります。 そのようなことがないように、不具合修正はこの手順を守って進めるようにしましょう。