不具合分析を行うための土台構築をした話
はじめに
こちらの記事はヤプリ Advent Calendar 2023の18日目の記事です。
（見事に遅刻投稿ですがご容赦ください）
はじめまして。QAエンジニアをしています。
ぐっさんと申します。
前提
まず前提として弊社では機能開発後にQA依頼用のチケットが作成され、QAはチケットに記載されている開発内容や修正による影響範囲などをキャッチアップしてQAを実施するというのをメインの業務としています。
チケット作成ツールはJIRAを利用しています。
（プロジェクト単位になるとQAフローも変わってくるため、今回紹介する記事内容からは割愛します）
今回は不具合分析に向けたJIRAチケットの再構築の話です
なぜ不具合分析をやろうと思ったのか
弊社のQAチームではクォーター毎にQA業務の中でKPTを実施しているのですが、その中でこんな課題が生じていました。
改修確認中、不具合の発生等で差し戻しが多い
差し戻しは多いが集計していないので増加件数がハッキリしていない
不具合修正後、直した以外の箇所でデグレが発生している
いずれもQAの方であればあるあるな課題かと思われます。
こちらの課題解決の為、差し戻し件数の集計、差し戻した不具合の発生要因の明瞭化を図るため、分析作業を始めようとしたのがきっかけです。
不具合分析を行うための土壌作り
分析作業を行うにあたり、まずは実際にどのくらいの差し戻し不具合、デグレが存在するか集計し、集計したデータを不具合要因ごとに分類化しようと計画しました。
ところが、差し戻した不具合はチケットのコメント内で起票されている状態だったので、集計が困難だということが判明しました。
そこで、まずは状態把握のため、現状のチケット記載方法、JIRAのフィールド設定、チケットフローの全てを洗い出し見直すことにしました。
チケット構成の見直し
やり方としてはシンプルですが、スプレッドシートに現在使用しているフィールドとフィールドに付随する記載内容を書き出して整理。そこからフィールドへ移管できるものを赤字で書き出して、JIRAで新規フィールドを作成しました。
集計しやすいよう体裁を整える名目でこちらの洗い出しを実施しましたが、
見直す過程で元々記載のあった項目が本当に必要かどうかを今一度検討する機会にもなったのが非常に良かったです。
また、チケットフローのステータス定義もこれを機に明示化して、フローとしてチケットのステータスをどこに置くべきかも再認識しました。
差し戻し不具合の分離化
続いて差し戻した不具合の分離化をするために、元のチケットから差し戻した不具合を別チケットとして起票できるよう「サブタスク」チケットとして起票することにしました。
サブタスクとして起票することにより、元々対応いただいた修正チケットの紐付けが自動ででき、進行状況が可視化できるようになりました。
発生事象、発生要因のフィールド化
差し戻し不具合を分離させた後、さらに分類するために発生した事象と発生した事象の要因をラベル化するためのフィールドを作成しました。
発生事象（一部）
強制終了、機能不備など
発生要因（一部）
要件定義漏れ、プログラミング誤り、影響範囲考慮漏れなど
これにより発生事象の傾向だけでなく、事象発生要因を集計することにより課題をシューティング、手戻りの発生頻度を減少させ、不具合の作り込みを防ぐように検討していく予定です。
その他行ったこと
その他、土台作りの一環として主に以下の作業を実施していきました。
・開発工程の再認識と整備
・集計ツールの検討と整備
・まとめた内容を開発チーム共有会で共有
まとめ
QAエンジニアにとって不具合の分析作業は肝になることが多いですが、まず何から手をつけていいか分からないということもあり、実際に私も分析をするために「まず何から手をつけていくか」というのは迷った点でもありました。
分析作業ということで、最初に不具合発生要因の項目分類の検討を真っ先に行いたくなりますが、不具合を起票するチケットの中身を整理することで、どのような項目が必要なのかを考えやすかったように思えます。
不具合の一つ一つに焦点を当てるよりも全体を俯瞰して、「分析をしやすくするためにどうすればいいか」、「現在の運用で分析作業するために不足している情報はないか」など地道ですが情報を一つずつ整理することが必要だと改めて思いました。
今年転職して初めて手がけた大きめの仕事ですが、今回は実際の分析作業ではなくあくまでも土台作りなので、より課題を抽出しやすくするようにこの運用をまずは開発チーム全体に浸透させるよう尽力していきます。
この記事が気に入ったらサポートをしてみませんか？