前回の続きです。
携わったプロジェクトで不具合の検出傾向を調べる必要があり、その内容を書き起こしました。

なぜ調査したのか

• 不具合の弱点を調査し、回帰確認を行うテストタイプが存在したため
  ※テストタイプは独自名称のため非公表

調査方針の検討

バグレポートを確認しながら、調査範囲やできることを整理しました

調査対象の不具合

• バグレポートがClose済みであること

• テスト実施工程の中盤～後半に検出された不具合であること
  ※テスト序盤は叩けば不具合が出る状態と聞いたため、調査しても弱点の本質が見えてこないと考えた

バグレポートで使えそうな情報

• 投稿日時

• 不具合が検出された機能の種類

調査したいこと

• 重要度毎の検出傾向

• 機能種別毎の検出傾向

• 不具合種別毎の検出傾向
  ※不具合の種類(例:機能,遷移,表示など)

• 操作毎の検出傾向
  ※不具合の検出起因となる操作(例:ボタン連打,NW通信OFFなど)

調査できないこと

• 不具合の混入工程、根本原因
  ※初回ローンチに向けた開発中 かつ Close済み不具合が約2000件あり、開発チームでこれらを調査するリソースが0だったため、PMに次回の開発があれば日頃から情報を蓄積しましょうと連携した

調査前に準備すること

• 不具合の重要度を定義

• 重要度,不具合種別,操作のフラグ付けをスプレッドシートで実施した

検出傾向のグラフ作成

前工程でフラグ付けしたスプレッドシートから「重要度」「機能種別」「不具合種別」「操作」の要素を組み合わせてパレート図を作成した

振り返り

良かった点

• 不具合の傾向をきちんと調査したのは初めてであるが、方針決めからゴールまで主体的に取り組むことで経験値を得ることができた

• ピポットテーブルの操作やパレート図の作成方法を理解することができた

• 本来の目的であるテストについて、単純な回帰確認だけでなく不具合が出やすい操作の観点を加えることができた

• テスト実行者の経験が浅く、探索的テストにおいて必要なスキルや経験値を不具合検出傾向を活用することで一部補うことができた

悪かったこと

• 各作業を進めるにあたり合意を得ていたステークホルダーが途中で退職した影響で、後任者との認識ズレによる作業の後戻りが発生することがあった。コミュニケーションや交渉事は相変わらず苦手である…

今後試せたら良いこと

• 今回のような調査で使用するフラグについて、日々の取り組みの中で起票者がバグレポートに登録するような運用にしたい

• 不具合分析（混入工程と根本原因の分析）にも取り組みたい