はじめに

Gunosy ではバグトラッキングシステム (BTS) として JIRA を活用しています。
今回は Gunosy でのバグトラッキングのワークフローの紹介と、BTS を運用して重要だと感じたポイントや、適切なバグトラッキングによって得られたメリットについて書きたいと思います。

Gunosy のバグトラッキングについて

バグのワークフローと JIRA を利用した管理

Gunosy の各プロダクトの QA 工程で、バグが起票されてから Close するまでのワークフローは下の図の通りです。

Gunosy の各プロダクトの QA 工程では多くのバグチケットが起票されますが、
JIRA のカンバンボードをプロダクト毎に分けて管理することで、現在の対応状況が把握しやすくなっています。
ワークフローとカンバンボードの列が一致するように設定しています。

上の画像は QA 工程が完了後の状態のスクリーンショットで、全てのバグチケットが Close の状態となっています。

ワークフローの詳細

[OPEND] バグの起票

テストで見つかったバグを JIRA に起票すると、ステータスは OPEND となります。
QA のテスト開始以降に発見されたバグは必ず BTS に登録してから修正する運用ルールとなっているため、
バグチケットの起票は QA メンバーに限らず、開発エンジニアが行うこともあります。
新規に起票されたバグは該当するプロダクトの Slack のチャンネルに通知され、開発・QA メンバーが確認できるようにしています。
[ASSIGNED] バグの担当者への割り当て・修正対応

バグチケットを Open した時点では担当者の指定は行わず、
開発の担当領域に応じてエンジニアが各自で担当するチケットを自分にアサインして、ステータスを ASSIGNED に変更する運用としています。
担当のエンジニアによって対応が完了したバグチケットは次の RESOLVED のステータスに変更されます。
[RESOLVED] バグの修正確認

RESOLVED に変更されたチケットはバグを起票した QA メンバーにアサインされ、修正確認のテストを実施します。
バグが再現する場合には、修正を担当したエンジニアに再アサインを行い、ステータスは ASSIGNED に戻ります。
[CLOSED] バグチケットの完了

修正確認で問題がなかった場合、QA メンバーがチケットを CLOSED のステータスに変更します。
今回のリリースで修正対応をせず、次回以降のリリースに持ち越すバグについても、チケットにその旨コメントを記載して Close します。
見送りのバグは定期的に棚卸しを実施し、修正時にはエンジニアがチケットを ReOpen します。
ワークフローの制限

JIRA で開発メンバーと QA メンバーに異なる権限を設定しており、ワークフローに以下のような制限を設けています。
・QA メンバーの権限ではチケットを Resolve できない
・開発メンバーの権限ではチケットを Close できない
・各ステータスにてバグチケットの必須の項目が未入力になっている場合はワークフローの遷移ができない
このように細かな制限を付けておくことで、イレギュラーな運用ができないようになっています。

バグトラッキングで重要なポイント

QA でバグトラッキングを行っている中で重要だと感じたポイントや、得られたメリットを以下に挙げます。

バグ対応の進捗状況をトラッキングすること
BTS の名前の通り、バグの状況をリアルタイムで追跡できていることが大切です。
バグチケットのステータスを常にアップデートしておくことで、各バグチケットの Open から Close までの進行状況をモニターでき、開発・QA を含め関係者全員がバグの進捗を把握できるようになることで、放置されるバグがなくなります。
また、JIRA のカンバンボードを利用することで、現在のチケットの担当者とステータスを簡単に把握でき、MTG でカンバンボードやチケットを見ながら相談したり、コミュニケーションのサポートになっています。
バグチケットの内容を明確にすること
全体のワークフローに加えて、各バグチケットの内容を詳細にしておくことも重要だと感じます。
開発エンジニアが原因の特定や調査をしやすくなるように、再現手順や期待結果と実際のテスト結果など基本的な情報はもちろん、再現率が低いバグの場合などは可能な限り多くの情報を記載するようにしています。
バグチケットの内容が明確になっていると開発と QA 間のコミュニケーションがスムーズになるため、バグの再現や修正対応を効率的に進めるためには必要な情報が正しく記載されていることが大切です。
対応履歴を残し、バグを蓄積させること
バグチケット上で確認内容や対応の履歴を残すことも重要なことの1つです。
バグチケットの各フィールドを適切に設定しておくことで、QA 工程が完了してアプリのリリースから時間が経っても各バグの対応履歴が確認でき、品質向上のためのバグ分析に活用できるようになります。
具体的には、JIRA のカスタムフィールドを利用して以下の内容を設定するようにしています。
- バグの起票時にバグ報告者が入力する項目
  - バグのタイプ:
    - 機能不全、UI/UX の問題、ログの問題、クラッシュなど
  - バグを発見した方法:
    - テストケース実行、Ad-hoc テスト、自動テストなど
  - バグの重要度:
    - 「必ず解決すべき」レベルから「解決しなくても良い情報提供」のレベルまで、4 段階から選択
- 開発エンジニアが対応完了時に入力する項目
  - バグの解決方法:
    - 修正対応済み、修正を行わない、仕様通りの挙動、次回以降のリリースに対応を持ち越しなど
  - バグの原因:
    - コード上の問題、仕様に関する問題、外部コンポーネントの問題、環境に起因する問題など

起票されたバグチケットが BTS に蓄積されることで、バグのデータベースが作られます。
バグの DB ができることによって、過去のバグの検索や、データをエクスポートして集計・分析ができるようになります。
QA チームでは蓄積されたバグチケットを活用し、バグの発生傾向について分析を行い、開発チームとともにプロダクトの品質向上に繋げられるように取り組んでいます。