不具合報告・対応フロー #bug

はじめに

私が考える不具合報告・対応のフローを紹介します。

不具合を発見したら、できる限り早くバグトラッキングシステム(BTS)に報告します。

不具合の報告に必要な情報は以下の通りです。

項目	説明
タイトル	不具合の内容を一言で表す
不具合内容	不具合の内容を詳細に書く
再現手順	他の人が再現できるように手順を示す
原因	アタリがついていたら書くこの時点では予測でいい
環境	不具合が発生した環境書かないと他の人が再現できないことがある　- システムのバージョン　- OSの種類とバージョン　- Webブラウザの種類とバージョン(Webシステムの場合) 　- その他システム独自の内容
報告者	不具合を報告した人(基本的には発見者)
報告日時	不具合を報告した日時(基本的には発見日時)
ステータス	「新規」とする

「報告者」や「報告日時」はBTSが自動的に取得するのが望ましいです。

不具合が報告されたら、その不具合を確認します。
報告者が自分で判断できる場合、報告と同時に確認した方が早いです。

項目	説明
再現できるか	再現性があるか確認する再現できない場合は報告者に聞くそれでも再現できない場合、ステータスを「保留」または「却下」とする
対応有無	対応が不要と判断したら、ステータスを「却下」とする
対応時期	対応が必要と判断したら、対応する時期やバージョンを書く
優先度	「緊急」「高」「中」「低」のようにざっくり付ける

対応時期や優先度により、対応する不具合を選定したら調査に着手します。

項目	説明
一時的な対応	根本的な対応に時間がかかり、致命的な不具合の場合、ワークアラウンドを書く
根本的な対応	根本的な対応方法を書く
類似の不具合	似たような不具合がないか調査する
ステータス	「調査中」→「調査完了」

対応方針が決まったら、実際に対応します。
類似する不具合が存在する場合、まとめて修正するのが望ましいです。

項目	説明
ステータス	「対応中」→「レビュー待ち」→「対応完了」

私が知っているBTSを紹介します。
私が紹介していないBTSを使っている場合、教えていただけると嬉しいです。

私が最もよく使っているBTSです。

よく使われているBTSです。
私は課題管理に使ったことがありますが、不具合管理として使ったことはありません。

GitHubを使って開発している場合、Issueを使うプロジェクトが多そうです。

なんか複雑な気がします、、
1年以上不具合の報告・対応を行っていないので、また始めたら更新します。