💨

【QA】0からバグ分析の仕組みを作って１年半実践した知見の共有(設計編)

2024/03/05に公開

現場でバグ分析を設計、運用したのでその内容を書き記しています。
全部書くと長くなったのでこの記事ではどう設計したかを記載しています。

背景

もともとチーム内でバグ分析やりたいという話は出ていたが、データの収集に適したツール（当時目を当てていたのはJIRA）でバグチケットの管理をしないと進められないという状況だった。

いっこうに進む気配がなかったので、少し手が空いたタイミングでスプレッドシートに情報を集めて、ピポッドテーブルを使って集計する仕組みを勝手に作った。

バグ分析を始めるといっても、勝手に初めてチーム内で共有してもなかなか協力が得られないので、しっかりチームのためになるための目標を設定した。

設定した目標

※バグ件数が少ないことのメリット

過去にいた現場で分析に使っていたものを参考に設定
はっきりとした目的があるものも有るが、何か見つかるかも？で取っているものも有る

項目名	説明	選択肢
Issue_No	バグチケットのID
開発案件	どの案件のバグか判別するため
タイトル	バグチケットのタイトル
テスト開始日	案件のテスト開始日
バグランク	バグの重大度を示したランク	S/A/B/C/D
種別	バグチケットの分類	新規/デグレ/既存/改善提案など
内容	バグの内容を端的に表したもの	仕様バグ/単機能バグ/デザイン崩れなど
原因	バグが埋め込まれた原因	仕様の不備/実装ミス/ など
改修機能	案件で改修した機能
案件種別	開発案件の分類	新機能追加/既存機能改修/不具合対応
開発工数	開発にかかった工数（ポイント）
テスト終了日	案件のテストが完了した日（=リリース日）
テスト工数	テストにかかった工数（人/日）
発生場所※	仕様の不備を対象にどこで不備が起きたか	横展開不足（機能、ユースケース）/UI文言/エラー（条件、文言）/ デザイン/仕様の伝達
対応方針※	バグチケットの対応方針	修正/対応不要/先送り
差し戻し回数※	バグチケットの差し戻し回数
検知するタイミング※	最速で見つけられたであろうタイミング	要件定義/開発中/テスト中
※ 後から追加した項目

取得したデータをどう使うかの検討
集計項目の設定と同時に行っている

JIRAが使えないのはわかっていたので、GitHubの内容に肉付けする形にするのは固定
集計はエクセルかorスプレッドシートの2択
メンバーに共有する時にスプレッドシートのほうが都合がよかったのでスプレッドシートを使用

VBAの代わりにGASを使えるのも選定理由の1つ

GitHubのチケットから内容をエクスポートするのはうまくいかなかったので、スプレッドシートへデータを集めるのは手作業になった。
そのため、チケットにデータを入力するのではなく、スプレッドシートの方に入力することにした。

案件ごとの情報と全期間での情報を見れるようにしたかったので、案件ごとにシートを分けることにして、全期間の情報を集めるシートを別途用意。

基本的に案件ごとのシートに集計したい項目をまとめていき、全期間のデータを集めるシートにコピーする形で設計。
全期間のデータを集めるシートにコピーするところはGASでスクリプトを用意してボタン１つでできるようにした。