背景
- 過去から、市場不具合の中で影響範囲の考慮が漏れており、テスト範囲外とした箇所で発生する不具合の割合が全体の3割を占めている
- 内容を分析するとQAチームでの考慮漏れもあるが、開発チームでも考慮できていないケースが多かった
- そこで、影響範囲を可視化することで、QA/開発双方で、影響範囲を想定しやすくする環境を構築中
ゴール
- 影響範囲の考慮漏れが起因する市場不具合数の削減
市場不具合をベースに可視化
全ての機能の影響範囲を可視化することは難しいため、市場不具合をベースに、変更元の機能と発生先の機能をラベリング
上記ラベルを基にして、変更元の機能と発生先の機能の2軸で表を作成
テスト設計時とテスト実行中の不具合修正時に参照
- 上記可視化した表を基に、以下のタイミングで利用
| フェーズ | 概要 |
|---|---|
| テスト設計 | 機能変更時、影響表から該当の変更元機能を探し、影響先機能をテスト設計に含める |
| テスト実行 | 開発側の不具合修正時、影響表から該当の変更元機能を探し、修正確認時に、修正箇所に加えて確認を行う |
運用は開発側と連携
- 市場不具合の発生した機能は、QAチーム側でも把握できる部分もあるが、変更元の機能は見えない部分が多いため、ラベリングは開発チーム側に依頼
- 導入時のみ、直近3ヵ月の市場不具合を一気に分析し、以降毎週発生した市場不具合に対して、ラベルを入力する運用に移行
導入結果
- 市場不具合ベースのため、見える範囲は限定的だが、導入前と比較すると、影響範囲の考慮漏れによる市場不具合数を半減させることに成功
現状の課題と今後の発展
- 普段の分析プロセスはBTSで実施しているが、今回はトライアルで別途スプレッドシートを用いてラベリングしたため、まだQA側から定期的に入力リマインドが必要な状況
- 今後は完全なフロー化に向けて、BTS側を改修し、ラベルを設け、既存の市場不具合分析プロセス内で対応する運用を検討中
- また、今回は市場不具合だけを対象としたが、次はQA中の不具合も対象にすることで、より信頼性を高めた形で、影響範囲を可視化していきたい