「ディフェクト・マス」と呼ばれる測定を導入することで、プロジェクトが開発において最も影響を受けた領域を見つけることができ、影響を受けた領域ごとに実行するテストの数を決定する役に立った。AxwayのエンジニアリングマネージャのVictor Ionascu氏はQA Challenge Accepted 2021で、測定を活用してどのようにしてより良いテスト戦略を作成するかについて話した。
Ionascu氏は、欠陥が多く、アーキテクチャに関する知識が不十分なプロジェクトに取り組むことについて自身の話を共有した。彼らは、データを引き出して、各機能領域に必要なテスト作業に関する考察を提供する式を作成することを決めた。彼らが作成した測定は「ディフェクト・マス」と呼ばれた。
ディフェクト・マスによって、インシデントの数とその重大度に基づいて、実行する必要のあるテストの数を計算します。
この測定値を他のKPIと一緒に使用することで、テストに集中することができた。Ionascu氏が説明するように、彼らは顧客のインシデントの数を減らすことができた。
どんなテストキャンペーンでも実行できるテストの数は限られており、確実に適切な領域に焦点を当てる必要があります。ディフェクト・マスは、この焦点を維持するのに役立ちました。
InfoQは、重要な製品領域のテストにディフェクト・マスを使用することについて、Victor Ionascu氏にインタビューした。
InfoQ: プロジェクトを開始するときに直面した主な問題は何でしたか。
Victor Ionascu: 私が参加したとき、プロジェクトは進行中でした。問題は積み重なっていて、軽減されていませんでした。問題を無視すると、問題はより深刻になる傾向があります。
直面した主な問題は次のとおりです。
- チーム間のナレッジトランスファーが不十分（ベルリン - ブカレスト）
- 影響の大きいバグが手動および機能テストキャンペーンから逃れていた
- 高い離職率が古い技術の原因となっている。持続的な製品からクラウド対応の製品に変更するための明確なロードマップがない
- 明確なアーキテクチャマップがない。製品の大部分がテストされていないままであり、顧客がその部分でバグに直面している
センター間には強い競争がありました。 R&Dベルリンチームは解散させられてブカレストに移されました。ベルリンに残った人（主にサービスチーム）は知識を共有することに積極的ではありませんでした。
InfoQ: 問題に対処するために活かせた強みは何でしたか。
Ionascu : このプロジェクトにはいくつかの強みもありました。秩序をもたらすためにそれを活用しました。
- 大量のドキュメント
- 企業プロセス
- サポートチーム
ドキュメントではいくつかのユースケースシナリオが提供されていました。製品のコンポーネント間の相互連携を詳しく説明した技術ドキュメントがありました。これにより、ロジックチェーンの構築が容易になり、最終的には、より的を絞ったテストケースを得ることができました。
企業プロセスによって私たちは、提供する方法と、どのようにして顧客がフィードバックを提供するかについての構造を持つことができました。
サポートチームは顧客と直接対話する最前線にいました。彼らは、顧客のユースケースを提供しました。そして、顧客が製品をどのように使用し、どのように設定したかについて現場からのヒントとコツを提供しました。私たちサイドで問題が発生したとき、私たちはサポート担当者と話し合って、構成に欠けているものがないかどうかを確認しました。
InfoQ: 何をテストし、どのようにテストするかを決めるのに役立つテスト戦略をセットアップするためのアプローチは何でしたか。
Ionascu: プロジェクトはほとんど暗闇の中で行われていたため、同じ傘の下ですべてのデータの収集を始める必要がありました。一部のプロジェクト情報はJiraにあり、他の情報はHP Quality Centerにあり、ある情報はSalesforceにありました。Jiraのすべてのデータを追加して、最も影響を受けた領域を特定し、作業を適切に集中させるための容量（人日）を見積もることができるようにしました。
私たちがしたことは次のとおりです。
- 私たちは、すべてのユーザーストーリー、エピック、バグ（内部および顧客のもの）、テスト（手動および自動）を収集する機能領域を使い始めた。
- 製品の所有者とミーティングを行い、各テストやテストカテゴリの重要性を確立することで、テストの適切な優先順位を設定した。これは、どれが重要なテストかをより適切に理解する役に立った。
- データを引き出し、各機能領域の影響を示す式を作成した。
- これらの影響を受ける各領域に対してどれだけのテストで十分かを判断できるように、テストにかける労力を見積もった。
ディフェクト・マスは、インシデントの数とその重大度に基づいて、リリースで実行する必要のあるテストの数を計算する概念です。
- コンポーネント = 製品の機能領域
- マス = エピックとバグの総量
- 1エピック = 1ブロッキング欠陥 = 10ポイント
- 1つの重大な欠陥 = 5ポイント
- 1つの軽微な欠陥 = 1ポイント
- 1日あたりの容量 = 1日あたりに実行するテストの数
- 日数 = テストキャンペーンの期間
- マス総量 = プロジェクト全体のマスの合計
私たちが作成した式は次のとおりです。
（コンポーネントのマス * 1日あたりの容量 * 日数）/マス総量 を小数点以下0桁に四捨五入 = リリースが正常に行われることを確実にするために実行する必要のあるテスト数
ディフェクト・マスを測定するツールを作成しました。このツールは、テストセットからいくつかのテストを抽出し、テストキャンペーンの計画を立てる役に立ちました。
試してみたい場合は、github: DefectMassからダウンロードしてみてください。
InfoQ: 何を測定しましたか。また、その測定は製品の品質を向上させるのにどのように役立ちましたか。
Ionascu: ディフェクト・マスを使い始めたとき、私たちは顧客のインシデントの発生を測定することによってバグの進化を絶えず調査しました。そしてバグは実際に加速度的に減少し、1年以上その傾向を続きました。
下のグラフは、ディフェクト・マスが実装された後、オープンとなっている欠陥の傾向がどのように変化したかを示しています。
InfoQ: 何を学びましたか。
Ionascu: 本当に明らかになったのは、私たちが最も影響を受けた領域に焦点を合わせ続ける必要があるということでした。しかし、焦点を合わせる前に、それらの領域が何であるかを知る必要がありました。
また、一貫性と忍耐力を保つことが重要です（チームと自分自身に時間を与えてください）。結果を確認して、それを追っていくには時間がかかります。
ディフェクト・マスを測定することに加えて、これら2つのKPIを使って、製品の品質をよりよく視覚化できるようにしました。
- 欠陥の漏れ=（リリース後に製品で見つかった欠陥の総数/リリース前に見つかった欠陥の総数）x 100
- 3か月の欠陥流入
私たちのプロジェクトでは、最初の結果は3か月後に現れました。テストアプローチを改善するのに役立つ、上記のようなより多くの指標（ディフェクト・マスは特効薬ではありません）が必要であることに気づきました。プロジェクトの品質を確認するために信頼できるツールはディフェクト・マスだけではないため、他のKPIも使用しました。
最後に、新しいアプローチを試すことを恐れないでください。