いまさら聞けないバグタスクのステータス管理

こんにちは、SODAでクオリティエンジニアをしているokauchiです。

今回は、バグタスクのステータス管理について、自分なりに整理してみました。普段の業務の中で、バグの進捗をどう管理するか、どのようにチームで共有するかは、意外と悩ましいポイントです。そこで、バグタスクのステータスをどう整理すれば良いのか、自分の中で考えたことをまとめてみました。

ステータス管理のフロー

まず、バグタスクがどのように進行するのかを視覚的に整理してみました。以下のような流れです。

このフロー図では、バグタスクがどのようにステータスが変化するのかが視覚的に示されています。実際にはここまで細かいステータス管理は行ってないのですが、出来るだけ細分化してみました。次に、この流れを詳しく解説していきます。

バグタスクのステータスとは？

バグタスクには、進行状況を管理するためのさまざまなステータスがあります。以下は上の状態遷移図であげたバグタスクのステータスです：

• New（新規）: バグが報告されたばかりで、まだ何も対応されていない状態
• Triage（トリアージ）: バグの優先度を決め、どれから手を付けるかを決定するとともに、やらないこと、つまり後回しにするバグも決める状態。これにより、どのバグにリソースを集中するかが明確になります。Todo、Backlog、Closedの3つのステータスに分岐されます。
• Todo（未着手）: 修正を行う意思決定がされ修正が必要な状態。タスクがAssigned（担当者割り当て）される前に、この状態になります。
• Backlog（保留）: トリアージ後に後回しにされたバグ。修正が必要だが、優先度が低いため、処理は後回しとなります。
• Closed（完了済み）: そのバグは対応する必要がないと判断された状態。Closedステータスに遷移します。
• Assigned（割り当て済み）: 修正担当者が決まり、修正作業が始まる状態。
• In Progress（進行中）: 修正作業が進行中の状態。
• Resolved（修正済み）: 修正が完了したが、テストや確認を待っている状態。
• Testing（テスト中）: バグ修正がテストされている状態。
• Verified（確認済み）: テストで完了し、バグが解決したことが確認された状態。
• Done（完了）: バグタスクが終了した状態。
• Fix Again（再修正）: テストで修正に問題が発覚した場合、修正が再度行われる状態。この場合、In Progressに戻ります。

もう少し細かく見ていくと、修正が決まったがより優先度の高いタスクが入ったことでどの状態からもBacklogに遷移したり、修正のアテが外れたことで簡単に修正できないことがわかり、その修正コストと起こっている現象を比較した時に対応せずClosedと判断することもあるかもしれませんね。

ステータスが見えるようになると？

バグの発生件数も気になりますが、これらのステータスの遷移でどこかで何日も滞留しているようなことが見えてくれば、何かしらそのステータスでの作業にボトルネックがあることも見えてきそうです。ReSolvedが何日も残ってしまうようなら、報告者だけが修正確認者になっていて、他に優先すべきタスクとバッティングが起こっているかもしれませんし、Todoがあまりにも多い場合は機能開発が優先するあまり担当者を決める、いつまでにやり切るが十分に議論されていない可能性があります。

まとめ

バグタスクのステータス管理は、QAエンジニアの重要なスキルの一つです。明確なステータス設計と管理フローを作成することで、タスクの進行状況を把握しやすくなり、チームの生産性を向上させることができます。また、ステータスの件数やそのステータスが開始してから次のステータスに遷移する時間もモニタリングできるとより良いです。特定の工程で問題が起こっているかもしれないことに気づきやすくなります。