BTSの解決状況(Resolution)は障害管理の名残り

Mantisのチケットでは、ステータスだけでなく「解決状況」も重要な属性だ。
又、Jiraのワークフローをカスタマイズしようとしたら、結構大変で、色々資料を探ったら、「ステータス」と「解決方法」をペアで設定する必要がある資料を見つけてようやく理解した。

各種BTSの解決状況(Resolution)について、情報をまとめてみた。
以下はラフなメモ書き。

【Bugzilla】
はじめてのバグジラ ver2.16-ja編
バグの重要度(Severity)
処理方法(Resolution)

【Mantis】
Mantisメッセージの日英対訳 - korakuriderの日記
Resolution=解決状況

【Trac】
Tracのチケットは終了基準が大切 - Basic

TracTickets -- MIST Project

チケットの使い方 - Meadow - Trac　チケットを閉じるときの resolution はどう選ぶべきか？ ¶

バグトラッキングシステムTracをつかう/TIPS集 - きのさいと
解決方法 (Resolution) - チケットが解決された際の理由。修正した (fixed)、無効なチケット (invalid)、修正しない (wontfix)、他のチケットと重複 (duplicate)、再現しない (worksforme)など。

【Jira】
JIRA ユーザーガイド

'解決状況' フィールドの値を定義する - JIRA (ジラ) 関連資料 - Go2Group Wiki

1.9.1. JIRA ワークフロー

【1】はじめてのバグジラ ver2.16-ja編にある処理方法(解決方法、解決状況：Resolution)の一覧が分かりやすい。
解決状況とは、バグがどのような作業によって終了したかの状態を表している。

普通のバグ修正ならば、「修正済み」(Fixed)で終わるが、「発見したバグは仕様通りです」という検証結果になったら、「修正しない」(Won't fix)になる。
あるいは、発見したバグは、以前見つけたバグの原因と同じなので、同類バグの扱いとなり、以前見つけたバグの修正と検証によって、「同件完了」(重複：Duplicate)で終了になる時もある。
あるいは、見つけたバグを再現することができず、修正方法が分からない場合は、「問題を確認できません」(worksforme)として保留状態となり、放置される。

BTSにおいて、解決状況を使う理由は、終了状態ごとにバグを集計して、システムの品質やテストプロセスの品質を探りたいからだ。
「修正済み」のバグが普通は多いだろうが、「重複」のバグが多いならば同類バグが多いことになり、バグの原因の深堀りが出来ていないことになる。
TestLinkなどのテスト管理ツールにあるブロックを使えば、似たようなバグを見つけることもなく、別の原因のバグを見つける工数を確保することもできたはず。

あるいは、「修正しない」バグが多いなら、そもそもテスターはきちんとテストしているのか、という疑いも発生する。
つまり、「重複」「修正しない」バグが多いなら、テスターの作業品質が悪いのではないか、という推測も成り立つ。

以下、Mantis、Trac、Jiraの解決状況の使い方について理解できたことを書いてみる。

【2】Mantisの場合、チケットのステータスは担当者の作業状態(修正中、解決済みなど)を表す。
チケットの解決状況はそのバグの終了状態を表すが、解決状況が「実装済み(Fixed)」の場合のみ、変更履歴画面に出る仕組みになっている。それ以外の解決状況では、ロードマップに表示されるものの、変更履歴画面に表示されない。

つまり、ロードマップに示された修正予定バージョンごとに、対応すべきチケットは一覧表示されるが、「実装済み」の解決状況の場合だけ本当にバグ修正されたので、変更履歴画面に示された修正済みバージョンごとに表示されることを意味している。
「実装しない」「保留」の解決状況のチケットは、ソースに何の修正も混じっていないので、変更された履歴に表示する必要もないわけだ。

【3】Tracの場合、解決状況はチケットの単なる属性に過ぎない。
普通は、MantisやBugzillaと同じく、チケットを終了する時に、その終了状態の意味を持たせることもできる。

Tracの優れたクエリ機能を使えば、解決状況ごとにチケットを集計して、プロジェクトの状況を探ることもできるだろう。

【4】Jiraの場合、解決状況はチケットの終了条件に関わる属性であるが、更にワークフロー設定と関係する機能になっている。
例えば、1.9.1. JIRA ワークフローによれば、ステータスが新規又は担当中のように作業中の場合は、解決状況は「オープン」のままになる。
そして、ステータスが完了になる場合、解決状況は「修正済み」「再現不可能」などの値を設定する必要がある。

Jiraの解決状況は、JIRA ユーザーガイドを読む限り、課題(チケット)を集計表示する時に重要な項目の一つであるようだ。

Jiraのワークフロー設定はRedmineと同様に自由にカスタマイズ可能だが、分岐が多くなるときちんと設計しなければ分からなくなるので注意。
普通は、ワークフローのテンプレートをあらかじめ作っておき、そのテンプレートを流用する方が良いと思う。

【5】だが、Redmineには解決状況というチケットの属性は存在しない。
カスタムフィールドを作れば対応出来るだろうが、あえて作る程でもないように思う。

結論を言うと、BTSの解決状況(Resolution)は障害管理の名残りだ。
チケット完了(Closed、Fixed)の定義が状況で異なる為に、解決状況(Resolution)が必要になったように推測される。

正直、BTSの解決状況(Resolution)はステータスに統一した方が運用は楽だ。
成果物が作られたり、その品質向上に役立つ作業のチケットは「終了(Close)」で終わるのが普通だろうが、中には「対応不要なので却下」「別のチケットと同じなので重複」「同類バグなので別チケットで対応」などのように終了状態が異なる場合もある。
バグの検証時に、ステータスの更新だけでなく解決状況という属性までも更新するのは二度手間のように思える。

終了の意味が違うならば、却下、無視などのステータスを増やせばいいだけのことだ。

Agile開発の場合、終了条件(Done)の意味はとても単純だ。
Doneとは、システムをリリースすること、つまり、顧客へ動くシステムを手渡すことを意味している。
Doneの意味を、ステータスや解決状況という属性にまで細かく分ける必要は特にはないはずだと思っている。