デフォルトのバグ ワークフロー
[編集]、[再割り当て]、[コメントの追加]、および [回避策の追加] の各アクションは、図から省略されています。
- [編集] と [再割り当て] は各状態に対してあらかじめ定義されており、変更できません。 これらのアクションは、問題の状態を変更しません。
- [コメントの追加] はすべての状態に対して定義されており、問題の状態を変更しません。
- [回避策の追加] は、[開発準備完了]、[QA 準備完了]、[QA やり直し]、および [対応完了] に対して定義されており、問題の状態を変更しません。
バグ ワークフローのデフォルトの理由コード
デフォルトのバグ ワークフローで提供されているすべての理由コードを確認するには、をクリックします。 問題の種類として [バグ] を選択すると、その有効なアクションと理由コードが表示されます。
例
デフォルトのバグ ワークフローの一般的な処理パスについて考えます。 報告されたバグは、[レビュー未完了] の状態でワークフローに入り、QA エンジニアの受信箱に送られます。 バグは、確認された後、開発者の受信箱 ([開発準備完了] 状態) に送られます。 開発者は、バグを解決したことを宣言し、[解決] アクションを実施します。 [解決] アクションは、理由コード [解決] を添えて、[QA 準備完了] にバグを送ります。 問題を受け取った QA エンジニアは、バグが修正されていることを検証します。 つまり、[検証] アクションが実施されて、バグは [対応完了] 状態に送られ、理由コードは [解決] が維持されます。
次に、前の例を少しだけ変更してみます。 QA エンジニアは、バグが修正されたという開発者の主張を却下するものとします。 バグは開発者の受信箱に戻されますが、今度は理由コードが [却下] になっています。 開発者は問題を再現できないため、[追加情報が必要] アクションを実施します。 バグは [QA やり直し] に送られます。 これに対し、QA エンジニアは、[重複として指定] アクションまたは [失効した問題] アクションのいずれかを実施して問題を完了させるか、または問題を明らかにしてからバグを [開発準備完了] に差し戻すことができます。