😸
【QA】0からバグ分析の仕組みを作って１年半実践した知見の共有(結果編)
こちらで書いた設定編の続きになります。
バグ分析のための仕組みを作って運用した結果や反省を書いていきます。
備忘録として時系列順に記載しているので、通してのまとめが見たい方は目次から全体通してのまとめに飛んでください。
全期間通して意識していたこと
- 手探りなところが多かったので極力他のメンバーの負担にならないように実施した
- バグの振り返りはバグの発生を防ぐことにフォーカスしたが、新しいルールを作る方向には行かないようにした
- ルールが増えていくと窮屈になるため
- ルールを作らないと、メンバーの意識に頼る部分が大きくなるのですぐに改善はできない
- 長く続けて少しづつ意識に刷り込んでいくつもりだった
- 進行中の案件のスケジュールに影響しないように実施した
- そのためレポートの作成が遅れることが有った
- なるべく感謝するネタを出す
第1期
期間：４か月くらい
バグ分析は手探りで始まり、エンジニアに負担をかけないようにするために当初はバグの原因をQA側で設定していたが、本当にあっているかどうかわからなかったためバグ修正後に原因を記載してもらうように依頼。
ざっと選択肢を出してこの中から選んでくださいという形にした。
用意した選択肢
- 仕様の不備
- 仕様の認識ずれ
- ユースケースの考慮漏れ
- 関連機能の考慮漏れ
- レビュー漏れ
- 実装ミス
- 手順ミス
- テスト環境
この期間はデータが集まるまで待ってからフィードバックしたため、フィードバックの回数は１度だけ。
ここで別のプロダクトへ移動したためいったん区切り。
反省
- 開発工数との関係を見ようとしたが、開発工数を集計するところまで作れなかった
- 原因の割合くらいしかフィードバックできていない
第2期
期間：1年半くらい
新しいプロダクトが運用期に入ってからバグ分析を再開。
フィードバックは3カ月データを収集した後に開始。
第1期の反省でフィードバックが足りないと感じていたので、月1でレポートを作成するようにした。
この時はレポートを共有する場は特に用意せず、バグの出方を見つつQAの立場だけでできる対策を考えていた。
ここで考えた対策を振り返りの場へ持ち込み、導入してもらう等していた。
途中でチケットの管理がGitHub → JIRAへ移行したためJIRAの機能を使えるように改修。
- 今までスプレッドシートで設定していた項目をチケットに設定できるように設定
- フィルター機能で必要な情報をピックアップしてCSVでダウンロード
- 案件ベースでシートを分けていたのを月ベースで分けるように変更
わかったこと
1年半ほど実施してみたが、件数ベースの分析ではあまり有益は情報は多く得られなかった
- 感覚的にわかっていることがデータ上でもそうなっていただけ
- 改修頻度の高い機能がバグの件数が多いなど
- 開発工数とバグの件数には相関関係が有るが、そこまで大きな関係ではない
- 中には、他より開発工数が多いのにバグの件数がすごく少ないものもあった
- 単純に開発工数よりは、開発時にどれだけその案件に集中できたか、影響を考えれたかの方が大きいと感じる
反省
- バグチケを対象にしていたので、バグが出なかった案件のデータが含まれておらず、集計結果が厳しめに出ている
- レポートは作成したものの、直接説明・共有しなかったのでチームの改善にはあまりつながらなかった
- 平均値を使う場合、標準偏差も出さないと信頼できる値かどうか判断できないと知らなかった
第3期
期間：4か月ほど
件数ベースでの分析では頭打ちと感じていたため、フィードバックを中心に据えて内容を変更
- 件数ではなくバグ1件を深堀する方針に変更
- 原因がどこにあったのか、どのフェーズで対策できたか、対策したらどんなものが有るかを共有できるようにする
- ↑の内容をバグ1件ごとに実施して週1の振り返りで先週でたバグの振り返りとして実施させてもらった
- バグチケにバグが埋め込まれたフェーズを設定する項目を追加
- どのバグを振り返りで取り上げるかは準備して持ち込み
反省
- 問題の共有とメンバー踏まえて対策を考えられたのはよかったが、その後改善されたかまで追うことが出来なかった
- 1人ですべてのバグチケの分析をしていたのでバグが多いと大変
- メンバーに品質意識を持ってもらうところまでは出来なかったと感じている
全体通してのまとめ
わかったこと
開発工数とバグの件数には相関関係が有るが、そこまで大きな関係ではない
- 中には、他より開発工数が多いのにバグの件数がすごく少ないものもあった
- 単純に開発工数よりは、開発時にどれだけその案件に集中できたか、影響を考えれたかの方が大きいと感じる
- 今回はバグの件数を減らすことを目的としたので、1件を深堀する方針に切り替えたが、傾向をつかむのが目的であれば、件数ベースでも良いと思います
バグが多発しそうな案件の特徴
- ほかのアプリケーションとの関連がある
- 管理画面/ユーザーページの両方を改修している
- 振り返りで仕様の認識ずれが問題視される
- pdmがタスクを持ちすぎて要件定義が進まない
実施時に気を付けること
- チームメンバーへのフィードバックは必須
Discussion