不具合分析を実施して品質カイゼンに繋げよう
こんにちは！QAエンジニアの入間川です。
株式会社COMPASSという小中学生向けAI型教材「Qubena（キュビナ）」を開発・提供する会社でプロダクトの品質保証を担当しています。
本記事では、弊社QAチームが取り組んでいる不具合分析について、ご紹介していきたいと思います！
不具合分析とは？
日々開発やテストを行う中で不具合が検出され蓄積されていきますが、これらの不具合に付属するデータを収集・分析して原因の傾向を探る活動の事を不具合分析と呼んでいます。傾向を把握し、適切な品質改善活動に繋げることを目的としています。
分析のための準備
不具合分析を始めるために、まず下記のような準備を実施しました。
不具合分析で計測・報告する内容の決定
①不具合総件数
まず、流出前後の不具合のトータル件数を取得します。下記の3点についての情報収集を目的としています。
リリース前、テスト活動の中で何件不具合が検出されているか
リリース後にどれだけ新規の不具合が検出されているか(これによってリリース前のテストで検出しきれなかった不具合がどれだけあったかを見ます)
リリース前に検出し、修正を見送ったものがどれだけ早くリリース後に修正されているか
②条件別不具合件数
下記の条件別に不具合がどれくらい発生しているかの件数、割合を取得します。不具合の発生傾向に関する情報収集を目的としています。
サービス別
不具合優先度(最高,高,中,低,最低)別
機能別
環境別
③欠陥、原因分類
不具合一つ一つに対し、どのような種類の欠陥であったか、どのような原因で仕込まれてしまったのかの分類を行います。欠陥の種類と原因の傾向を探る事で適切な改善活動に繋げることを目的としています。
④チケットクローズ理由
チケットがクローズされた時、どのような理由でクローズされたかの情報収集をします。「仕様通り」や「既知不具合のため」のような理由が多い場合は適切な不具合起票ができていないとみなして改善策を検討します。
⑤流出不具合テスト実施状況
リリース後に検出された不具合のうち、特にクリティカルな不具合＆対応優先度高の不具合に絞ってリリース前のテスト実施状況確認を行います。
リリース前に実施するべきであったが漏れてしまったテストケースやテストスコープの見直しをすることを目的としています。
⑥テスト項目内／外
優先度ごとに、テスト項目内で検出できた不具合、テスト項目外での検出となった不具合の件数を集計します。
リリース前のテストで優先度の高い不具合をどれだけ拾えたか、どれだけ検出漏れがあったかの情報をテスト品質を見る一つの指標としています。
メトリクスの決定
続いて、不具合分析を進めていくためにどういった情報を収集する必要があるかのメトリクスを定義することから開始しました。
テスト実行時に起票する不具合チケットに記載する事で集めたいデータ、リリース完了後に入力し集めたいデータをそれぞれ定義しています。
不具合起票ツールへのフィールド追加
弊社ではプロダクト開発ユニット全体でAsanaというタスク管理ツールを使用しています。
不具合チケットもAsanaプロジェクト上へ全て起票されていくので、まずはこの不具合管理プロジェクトへ収集したいメトリクスのフィールド追加を実施しました。
不具合管理プロジェクトはリリース前テスト時に起票する「流出前不具合管理プロジェクト」、リリース後の本番環境で検出された「不具合管理プロジェクト」の2つに分けて運用を行っているため、それぞれに対してフィールド追加を行いました。
また、社外からのユーザー問い合わせ・不具合報告も「リリース後に市場流出した不具合」としてカウントする必要があるため、ディレクターとカスタマーサポートチームに協力頂き、問い合わせチケットのデータのフィールドも一部不具合管理と揃えて頂きました。
イテレーションに合わせた不具合情報収集
続いて不具合の情報収集を行っていきます。弊社では週に1回リリースが行われていますが、Week 1(チケットベースの不具合修正対応〜リリースの週)、Week 2(ユーザーストーリーの新規開発／テスト設計が必要なアイテムの対応〜リリースの週)のように週毎にリリースするアイテムを区別し、実質2週間で大きなサイクルが一つ完了するようなリリースサイクルとなっています。不具合分析はこの2週間のサイクルで扱ったアイテムの開発〜テスト活動を分析対象としています。
上記のスケジュールに沿う形で不具合チケットが起票されていきます。
基本的には必要な情報は不具合起票時に全て入力がされているのですが、下記4つのみリリースの後から入力を行っています。
欠陥が混入した工程
欠陥分類
リリース前テスト実施状況
原因分類
入力の際は、それぞれのプロダクトの開発チームに協力頂き、不具合一つ一つの欠陥分類、原因分類についてヒアリングを行います。ヒアリング結果を下記のように入力し集計をしています。
ここの情報を入力する際に、初めは開発チーム内のデイリーMTG内で少しお時間を頂きヒアリングを行っていました。チームで不具合の種類や原因について会話をすることで、「実は実装前にこんなことが起きていた」「今定義されている分類にはどれにも当てはまらなそう」といった、チケットを見ているだけでは知り得なかった情報がたくさんチーム内から出てきており、大変有意義な時間となったと感じます。欠陥／原因の分類定義のブラッシュアップにも繋がりました。
1ヶ月弱程デイリーMTG内でのヒアリングを続けた後、現在はSlackで実装担当のエンジニアの皆様にファイルへの入力依頼をする形に切り替えています。今後はレポート完成後の報告会の中でチーム内で分析結果を見ながらディスカッションをしていければと思います！
チーム内での不具合に関するヒアリング、ディスカッションについてはエムスリーテックブログ「不具合分析会を1年やったら品質だけでなくチームの能力も向上した」の活動内容も参考にさせて頂いています！
不具合分析実施
不具合情報の収集が完了したら、次は集計・分析を行います。
弊社では全チーム横断でAsanaで不具合起票を実施しているため専用のバグ管理・分析ツールなどは使用せず、Googleスプレッドシートにプロジェクト情報を週に1度社内ツールで自動出力してから集計、分析を行っています。
Asanaの「流出前不具合管理プロジェクト」「不具合管理プロジェクト」および「ユーザー問い合わせ」の情報を一つのスプレッドシートに集約し、ピボットテーブルで集計していきます。
まずは目的とする情報を半自動で取得する仕組みを作ることができてきました。集計・分析を更に自動化していく為の取り組みも継続して実施していきたいと思います！
レポート作成・報告
情報収集、分析が完了でき次第、レポートの作成です。
スプレッドシートでの分析結果から、レポートのテンプレートに沿って情報を入力していきます。分析の中から抽出された課題に対する施策、総評についてもレポートの中に明記します。
レポート作成が完了したら、各プロダクトチームのデイリーMTG内での結果
報告＆「テスト品質カイゼン会」での報告を行います。
※「テスト品質カイゼン会」とは、QAチームが所属するプロダクト推進部のメンバーで実施している改善会です。開発ディレクターとQA、第3者検証の協力会社さんが参加する、COMPASSの全プロダクトを横断して品質改善活動について検討する会となっています。
この会での取り組みについても今後別記事でご紹介したいと思います！
まとめ
不具合分析の仕組みが回り始めたばかりで実施回数はまだまだ少ないですが、リリース後の市場流出不具合が0件というイテレーションもあったりと現時点でかなり高品質な状態での開発・テストのプロセスが回っているということがわかりました。(すごい！🎉)
引き続き不具合分析を継続的に実施し、課題抽出・施策の検討を行うと同時に、品質に対して日々高い意識をもって取り組んでくれているチームの皆さんにポジティブなフィードバックができる根拠としても利用していければと考えています。
また、現在は主にシステムテストフェーズでの不具合にフォーカスして不具合分析を行っていますが、今後は欠陥検出率・テスト密度、バグ密度等の品質指標も取り入れたいと考えています。ユニットテストや結合テスト、ドキュメントレビューなどで検出された不具合情報も収集することで、さらに開発プロセス全体を通した品質カイゼン活動を推進していけるチームを目指して行きたいです！
最後に、COMPASSでは様々な職種で採用活動を積極的に行っています！
ご興味のある方はぜひご連絡ください！
COMPASSの公式noteです。こちらもぜひご覧ください！
この記事が気に入ったらサポートをしてみませんか？