さぁ、楽しいバグ取りの時間だ — バグに対してのワークフロー

現職でも前職でも JIRA というバグトラッキングシステムを使っています。

バグが報告された時にどのようなフローで処理するかをざっとまとめてみました。

チケットの発行

報告のあったバグはシステムに登録されます。

登録されたひとつひとつのバグはチケット (ticket) と呼ぶことが多い感じです。

以前の会社では issue とも言っていました。JIRA のシステム上では issue となっています。

ちなみに英語では……
"raise a ticket (an issue)", "create a ticket (an issue)", "make a ticket" と言ったりしています。

バグの報告内容

• 概要 (Summary)
• テストしたソフトウェアバージョン
• テストしたハードウェアならびに OS とそのバージョン
• 再現手順
• スクリーンショットやムービー

バグは再現性があるかどうかが肝で、再現する手順が明らかならば、そのバグは八割方直ったも同然です。

バグに対してのアクション

プロジェクトの進行状況や日程などによって変わりますが、バグが報告された際、すぐに修正作業に入ることはまれです。

• レポーター (Reporter)
  バグを報告した人。テスターでなくてもバグの報告者になりえますが、テスターがレポーターになることが多いです。

• ディスパッチャー (Dispatcher)
  バグの優先順位を決めたり、割り当て分担を決める人。テクニカルリーダーがこの役目を担うことが多いのですが、プロジェクトマネージャーやシステムエンジニアがチケットの割り当てを行うこともあります。

• 担当者 (Assignee)
  バグの修正作業を行う人。当然ながら開発者 (デベロッパ) がバグ修正を行うことが多いです。

基本的な流れとしては、

1. レポーターからバグの報告を受ける
2. ディスパッチャーが各開発者の負荷や開発範囲を考慮して、それぞれのバグを開発者に割り当てる
3. 開発者がバグを修正する

という形になります。

トリアージと優先順序

もちろん報告されたバグは全て直すのが理想ですが、リリース日程がタイトな場合には、全てのバグを直すのが事実上不可能なことがあります。

その場合、報告を受けたバグに優先順位をつけて、どのバグから優先的に修正するか、もしくは、修正しないことにするか (修正するにしても次のバージョンアップで修正する) などを決めていきます。

以前勤めた職場では、優先順位決定プロセスを「トリアージ (triage)」と呼んでいました。

災害などの非常事態に行う医療トリアージから来ています。

例えば、優先順位としては、以下のようなものが挙げられます。

順位	内容
P1	緊急。アプリケーションがクラッシュするなど、このバグのために他のテスト作業や開発業務ができない。深刻なセキュリティの脆弱性など
P2	重要。リリース前に直すべきバグ。アプリケーションが要求仕様通りに動作していない
P3	不具合だが回避方法がある、ミススペルや翻訳不備などのローカライゼーション系不具合、などの緊急度の低いバグ
P4	見た目だけの問題や微妙な挙動の一貫性不備、などの動作そのものには影響しないバグ

これは一例ですが、基本的な優先順位の意味付けはチーム内で共有しておく必要があります。

トリアージは以下のようなメンバーで行います。

• テクニカルリーダー (あるいは、プロジェクトマネージャ)
• システムエンジニア (あるいは、デザイナー) : 仕様作成者
• テストリード
• シニアソフトウェアエンジニア

これに (チケット内容の詳細を確認するため) レポーターが参加したり、実装の詳細をしっているエンジニアが参加したりする場合があります。

ソフトウェアリリース

バグに対してのワークフローからは少し脱線しますが、バグの優先順位はソフトウェアのリリースと関連付けられる場合あります。

ソフトウェアのリリースに関しては、正式公開されるまで

• 基本仕様の実装完了 (Feature Complete)
• アルファ版 (Alpha)
• ベータ版 (Beta)
• リリース候補版 (Release Candidate)

というような内部リリースの段階を踏みます。

リリース予定日から逆算してスケジュールを組むことが多いと思いますが、この内部リリースの大まかな定義 (目標) として、優先順をつけられたバグの数を使うことがあります。

つまり……、

リリース	内容
Feature Complete	仕様実装がほぼ完了。新規機能追加を基本的に行わず、テストフェーズに移行
Alpha	最優先のバグ (P1) = 0。追加仕様の実装
Beta	重要なバグ (P2) = 0
Release Candidate	その他、バグを可能な限りなくす。P3 バグ = 0 が目標

内部リリースのフェーズに応じて、その時点で残っているバグの優先順位の見直しが行われます。

場合によって、緊急度の低いいくつかのバグは次期バージョンに持ち越しされることもあります (defer)。

チケットの状態

報告されたチケットは、担当者に割り当てられるまではディスパッチャーが預ります。

チケットの状態 (status) にはおおよそ以下のように分類されます。

状態	内容
公開 (Open)	チケットを受理。修正作業に入る前の状態
作業中 (In Progress)	担当者が当該チケットの修正作業中
修正済 (Resolved)	担当者がバグを修正し、テスターに検査依頼
完了 (Closed)	テスターが修正内容を確認し、修正の承認が終了した状態

会社やプロジェクトによっては、更に以下のような状態が追加されている場合もあります。

状態	内容
新規 (New)	Open の前段階。担当者に割り当てられる前の状態。New がない場合は、Open が New を兼ねる
検査中 (Testing)	Closed の前段階。テスターが修正内容を検査中。Testing がない場合、Resolved が Testing を兼ねる

担当者のアクション

担当者はバグを修正して、テスターに「修正済 (Resolved)」として渡す役目を担いますが、単にソフトウェアを変更して「修正」する以外にもいくつか取りうるアクションがあります。

状態	内容
修正完了 (Fixed)	ソフトウェアを変更し、バグを修正した
再現不可 (Cannot reproduce)	報告されたバグが再現できないため修正が困難。レポーターないしテスターに差し戻し
重複 (Duplicated)	他のチケットとしてすでに報告されている
修正不可 (Won't fix)	外部要因 (ハードウェアあるいは OS もしくはサードパーティライブラリ) による制限により修正不可能
仕様 (By design)	「それは仕様です (Working as intended)」

先述した通り、バグは再現性が非常に重要です。開発者の環境で再現できれば、そのバグは八割以上直ったのも同然とも言えます。

「再現できない (I could not reproduce/replicate it)」場合は、レポーターもしくテスターに差し戻して手順や条件の見直しをしてもらいます。

フロー概要図

以上を踏まえて、ざっと図にまとめると以下のようになります。

人物っぽいシンボルについては

• D : 担当者。主に開発者が担う。
• L : ディスパッチャー。主にテクニカルリーダーが担う。
• T : テスター。修正されたバグを検査する

のようになります。

レポーターは前述のとおり、テスターが担うことが多いのですが、必ずしもテスターがレポーターになるという訳ではありません (バグの報告は誰でもできます) 。