QAの重要メトリクストップ20

現在、ソフトウェア開発パイプラインに品質保証に特化したメカニズムを組み込む必要性は明らかです。QAカバレッジが不足していると、単にアプリケーションが水準に満たないだけでなく、ユーザーエクスペリエンスが貧弱で、ブランドの信用性に悪影響を与えることにもなります。

実際、多くのテクノロジー重視の企業はQAに多大な投資を行っています。Sogetiの「13th edition of the World Quality Report」では次のように報告されています。

「品質トランスフォーメーションの加速化がいたるところで見られ……品質保証の重要性は増加しています。1,750人のCIOおよびシニアテックリーダーを対象とした私たちの調査は、テストの価値がかつてなく高まっていることをはっきりと示しています」

とはいえ、投資の増加を正当化するには、ソフトウェアテストの結果を注意深く継続的にモニターする必要があります。必然的に、ステークホルダーは適切なメトリクスを必要とします。これは、QAのパフォーマンスや開発プロセスの強化におけるQAの役割を評価するためです。

「計測できないものは改善できない」という昔からの教えに従って、テストプロトコルおよびチームの効率を明らかにするのに役立つ必須のQAメトリクス20個をまとめたのが以下のリストです。

定量的/定性的QAメトリクス

リストの説明に入る前に、QAメトリクスの2つの大きなカテゴリ – つまり定量的メトリクス(絶対値)および定性的メトリクス(派生メトリクス)について簡単に見ておきましょう。

定量的メトリクス(絶対値)

定量的メトリクスは、文字通りのものです。自然数であり、QAプロセスの単一の側面を計測します。定量的メトリクスには次のようなものがあります。

見逃されたバグ数
要件ごとの欠陥数
特定の期間に実行されたテスト数
テストレビュー率
欠陥捕捉率
テストごとの平均バグ数
テスト時間
テスト費用
バグ修正ごとの費用
ソフトウェアの変更ごとの欠陥数

定性的メトリクス(派生値)

定量的メトリクスは、それだけではQAチームのパフォーマンスの全体像を示すことはできません。たとえば、テストごとの平均バグ数そのものには、テスト実行の総数やテストごとの平均実行時間などのコンテキストの中で見ないかぎり、それほど意味はありません。この点で、定性的メトリクスが役に立ちます。定性的メトリクスは、相互を補完する複数のメトリクスを関連付け、チームのスピード、正確性、効力などの複雑な状況を表すことができます。

定性的メトリクスには次のようなものがあります。

テストカバレッジ
テストの信頼性
未テストのコスト
テスト実行ステータス
欠陥の分布の推移
欠陥の解決
テストケースの有効性
欠陥検出漏れ率
テストケースの生産性
テスト完了ステータス
テストレビューの効率

QAの重要メトリクストップ20

1.見逃されたバグ数

QAが存在する一番の理由は、多くの(理想的にはすべての)バグが運用に入り込まないようにすることです。理想的には、アプリケーションまたは機能がリリースされた後に顧客が大きなバグを見つけてレポートする必要がないようにするべきです。

そのため、見逃されたバグ数はQAプロセス全体を測る主要なメトリクスであるべきです。顧客がバグをレポートせず、緊急に修正を実施するために何もかも一時中断する必要がないなら、QAアクティビティはプラスの結果を生み出していると言えます。

しかし、大きなバグが繰り返し見逃され、ユーザーエクスペリエンスを妨げているのであれば、テストスイートを再検討する必要があります。ありがたいことに、顧客からバグがレポートされた場合、アーキテクチャ全体を再検査しなくとも、すばやく問題の場所やパターンを突き止めることができます。

しかし、現実的には、潜在的なバグをすべて運用に到達する前に検出して解決するのは不可能です – 特に、リリースのスケジュールが厳しい場合には。それでも、それほど顧客の迷惑にならない、すぐに修正可能なバグについて、許容可能な数を決定することができます。

たとえば、新機能を3週間でリリースする必要がある場合、製品にまったくバグがないことは保証できません。そこで、機能の主要な目的と主なユーザーパスを確認する時間を取ります。その後、主要なパスがバグによって破綻しないこと、また新機能が既存のUI/UXを壊していないことを確認します。

運用で比較的小さなバグが発見される場合もあるかもしれませんが、それほどUXのさまたげにはならないと考え、主要なパスのバグを解決することに集中します。

最後に、このメトリクスを評価する際、大きなバグが見逃されていないかを判断します。大きなバグが見逃されているのであれば、テストを追加したり、既存のテストを修正する必要があるかもしれません。

もちろん、長期的には、あらゆる潜在的なバグを捕捉できるようなエンドツーエンドテストスイートを設計することを目標とすべきです。それには時間と、綿密な計画と、実際のテストからの学習が必要です。そのため、上記のような枠組みで優先順位を付けましょう。

2.テストカバレッジ

テストカバレッジメトリクスは、「テストをいくつ実行していて、ソフトウェアのどの領域をカバーしているか？」という質問に答えられなければなりません。

パーセンテージとして計算されるテストカバレッジは、既存のテストによってアプリケーションがどの程度検証されているかを表します。

テストカバレッジは、次の2つの簡単な式で計算できます。

テスト実行 = (既に実行されたテストの数/実行する予定のテストの総数) x 100
要件カバレッジ = (既存のテストでカバーされる要件の数/要件の総数) x 100

2つ目の式は、QAによってすべての(または大部分の)ソフトウェア機能がチェックされたことを検証するのに特に重要です。たとえば、単に500個のテストを実行しても、自動的に高い品質が保証されるわけではありません。テストが重要なユーザーパスやコア機能のパフォーマンス、明らかな顧客の傾向をカバーしている必要があります。

3.要件ごとの欠陥数(要件欠陥密度)

各要件をカバーするテストで見つかった欠陥の数をモニターすることは非常に有益です。このQAメトリクスは、他の要件よりリスクの高い要件を明らかにし、そういった機能をリリースするべきかどうかを製品チームが判断するのに役立ちます。

特定の要件のテストであまりにも多くの欠陥が発見される場合、要件自体に問題があることを表している可能性があります。もちろん、テストケースのリファクタリングが必要な可能性もありますが、テスト構造の欠陥のせいで、より多くの欠陥が発見されるというケースはまれです。

たとえば、要件Aのテストで38個の欠陥が見つかり、要件Bのテストでは7個だけだった場合、テスターにとっては、要件Aのテストを修正する必要がないかを調べるべきサインです。いっぽう、現状で要件が現実的にデプロイ可能ではない可能性があることを示すサインでもあります。後者を判断するため、開発者や製品マネージャーに相談します。

4.テスト作業

テスト作業を評価するには、他の複数のメトリクスを考慮に入れる必要があります。それらのいわばサブメトリクスは、どれだけのテストが実行され、どれほどの時間がかかっているかを反映します。テスト作業数は、通常は平均値として計算され、十分なテストを実行しているか、また十分な欠陥を捕捉しているかを判断するのに役立ちます。

重要な作業数には以下のようなものがあります。

(期間)ごとのテスト実行数: 実行済みテスト数 / トータル期間
テストレビュー率: レビュー済みテスト数 / トータル期間
欠陥捕捉率: 捕捉された欠陥総数 / トータル実行期間
テストごとの平均バグ数: バグ総数 / テスト総数

5.テストの信頼性

完璧なテストスイートには、次のような特性があります:

バグの数と失敗したテストの数に密接な関連がある
失敗したテストは、不安定なテスト(flaky test)ではなく、すべて実際のバグに関連している
テスト対象の機能に完全にバグがない場合にだけテストが成功する

上記のような指標に近いほど、テストスイートの信頼性は高くなります。ここでいくつか重要な疑問があります。

テストが失敗しているのは実際のバグのせいか、それともテストの設計が悪いせいか? テスト設計の問題である場合は、いくつのテストが該当するか?
テストは不安定ですか? 不安定な場合、いくつのテストがどれだけの頻度で不安定な動作になるか?

QAが適切にソフトウェアをテストしている – 実際にQAの仕事をしているという信頼を得るには、テストの信頼性を追跡する必要があります。あらゆる有効なQAメトリクスと同様に、テストの信頼性は、テスターが継続的に既存のテストケース、シナリオ、プラクティスの改善を行うのに役立ちます。

6.テスト時間

このメトリクスは、テストチームまたはテスターが、ソフトウェアの品質に影響を与えることなく、どれほどすばやくテストを作成し、実行できるかを明らかにします。

もちろん、手動テストサイクルか自動テストサイクルかによってメトリクス値は異なります。自動テストのほうがはるかに速く実行できるでしょう。さらに、QAに使用されるツールやフレームワークもテスト時間に相当な違いをもたらします。

これらの数値を組み合わせるのは困難な場合があるため、以下の平均値を使用します。

平均テスト作成時間 = 総テスト作成時間 / 作成済みテスト総数
平均テスト実行時間 = 総テスト実行時間 / 実行済みテスト総数

QAチームのパフォーマンスに関するこれらのメトリクスの初期値を取得したら、両方の平均値を改善するためにベストプラクティスを取り入れたり、ツールをアップグレードしたりできます。平均時間を短縮できても、品質水準が下がっては意味がないことに注意してください。

7.テスト費用

たいていのQAチームは一定の予算内で作業する必要があります。費用を正当化するには、計画された支出額と最終的な支出額を細かに記録する必要があります。主要な2つの値は次のとおりです。

テストに割り当てられた費用総額: 経営層が一定期間(四半期、年度など)にQAアクティビティに対して承認した費用額です。
実際のテスト費用: 必要なテストを実行するのに充てられた実際の費用額です。費用の計算には、時間あたり、テストケースあたり、または要件あたりのテスト費用などが含まれます。

たとえば、割り当てられた費用の総額が2000ドルであり、200個の要件をテストする必要がある場合、

要件あたりのテスト費用は次のとおりです: 2000/200 = 10 ドル

テスト時間あたりの費用は次のとおりです: 2000/テスト時間数 (例: 200 時間) = 100 ドル

テストケースあたりの費用は次のとおりです: 2000/テストケース数 (例: 50個) = 40 ドル

上記の例は、すべての要件が同じ時間と同じ費用でテストされると仮定しています。しかし、現実はそうではないことが多いため、現実に合わせてQAメトリクスの計算方法を調整する必要があるでしょう。

8.バグ修正ごとの費用

簡単に言えば、このメトリクスは、開発者によるバグ修正ごとにかけられた費用です。

バグ修正ごとの費用 = 修正にかかった時間 * 開発者の時間単価

バグ修正ごとの費用をさらに細分し、最終的なレポートではよりわかりやすい数値を表示することもできます。

9.未テストのコスト

未テストのコストの計算はわかりにくく感じられますが、QA機能の必要性を立証するよい方法です。ステークホルダーに対して予算の増額や増員を正当化する必要がある場合は特に、このQAメトリクスをモニターすることが重要です。

未テストのコストとは、テストなしで運用に入り、エラーが発生して修正が必要になった機能を修正するコストを指します。

欠陥の修正にかかる開発者の時間に基づいてコストを計算できるほか、次のような主観的コストを含めることもできます。

顧客からの電話およびサポート要請への対応時間の増加
製品ダウンタイム
顧客からの信頼、ロイヤルティ、ブランドの信用性の低下

未テストの機能は、単なる機能不全をはるかに越える影響を及ぼす可能性があります。そういった影響を明らかにしてくれるカスタマーサポートや製品チームの担当者と確実に連絡が取れるようにしましょう。

10.テスト実行ステータス

任意の時点で、いくつのテストが成功、失敗、保留、未完了、未実行であるかに関して正確な情報を取得できる必要があります。このメトリクスは数または率で表され、日ごと/週ごとのレポートに不可欠です。また、これらの数値は以前のベンチマークと比較できるため、チームの平均的な効率を簡単に把握することもできます。

ヒント: テスト実行ステータスの数値を棒グラフや円グラフなどのわかりやすい視覚的表現にすると、レポートに役立ちます。実際問題として、生の数値は目を引きません。

11.ソフトウェアの変更ごとの欠陥数

新機能が追加されたり、既存の機能が変更されたりしたとき、変更をテストすると、以前のテストでは発生しなかった欠陥が判明することがよくあります。たとえば、ウェブページにボタンを追加した場合、以前は問題なく表示されていた既存のボタンがおかしくなり、テキストがずれることもあるでしょう。つまり、純粋に新しく変更があったことで欠陥が発生したのです。

仮に5つの変更を行ってテストした後に25個のバグが見つかった場合、各変更につき約5個のバグと換算できます。もちろん、1つの変更が他の変更より多くのバグを入り込ませている可能性は常に存在します。

このQAメトリクスをある程度の期間にわたって複数のプロジェクトで観察していれば、各変更ごとにいくつのバグが予期されるか、情報をもとに予測できるでしょう。この数値を把握していれば、新しくテストサイクルを始めるときに、時間、リソース投資、稼働状況について、より高い精度で計画できます。

12.欠陥の分布の推移

テストサイクルが終了したら、いくつ欠陥があり、どこで発生したかをグラフにするのが重要です。すると、QAチームがテストサイクルを重ねるにつれて、より多くのバグを検出し、解決できているかが明らかになります。

また、欠陥を発生元ごとに分類すると、より注意が必要な領域を特定するのにも役立ちます。よくある分類方法には、次のようなものがあります。

原因別欠陥分布
モジュール別欠陥分布
重要度別欠陥分布
プラットフォーム別欠陥分布

特定のカテゴリで欠陥が増えている場合、原因を特定するのが比較的容易でしょう。たとえば、1つのプラットフォームで他より多くの欠陥が見つかっている場合、ソフトウェアをその環境により合ったものにカスタマイズする必要があることを示唆しているかもしれません。

13.発見されたバグ/修正されたバグ

発見されたバグ/修正されたバグメトリクスは、QAプロセスの効率を判断するのに重要なメトリクスの1つです。このメトリクスは、発見されたバグの数と修正されたバグの数を比較することで、QAが本来の業務を行っているかどうかを示す客観的な率がわかります。

この解析は、どのようにバグが見つかり、除去されるかというパターンを特定するのにも役立ちます。このメトリクスは、欠陥管理の現況に対する重要な知見を提供します。

このメトリクス値を算出するには、まず、テストサイクル期間中、毎日発見されたバグと修正されたバグの数を追跡する必要があります。たとえば、テストサイクルが5日間だとすると、次の値を収集します。

テストサイクル日	起票されたバグ	解決されたバグ	その日までに起票されたバグの総数	その日までに解決されたバグの総数
01-09-2022	6	4	6	4
02-09-2022	3	0	9	4
03-09-2022	4	4	13	8
04-09-2022	2	4	15	12
05-09-2022	2	3	17	15

テストサイクル終了までに、17個のバグが起票/検出され、15個のバグが解決されました。これを以前のテストサイクルと比較すると、テスターのバグ発見および修正能力が向上しているかどうかがわかります。

14.欠陥解決率

このメトリクスは、QAチームによってレポートされたバグを分析し修正する際の開発チームの効率を明らかにします。理想的には、QAがバグの解決を気にするべきではありませんが、この値を追跡すると、特にマネジメント層と話をするとき、リリースの遅れを説明するのに役立ちます。

このメトリクスを算出するには、開発チームにレポートされた欠陥の総数と、テストサイクル期間内に修正された欠陥の総数を追跡します。その後、次の式に従って計算します:

欠陥解決率 = (修正された欠陥の総数 / レポートされた欠陥の総数) x 100

SDLC全体でQAが効果的であるかどうかを評価するために、欠陥解決率の推移を追跡します。

15.欠陥の存続期間

欠陥の存続期間は、欠陥が見つかったときから実際に解決されるまでに開発者が欠陥の修正にかけた時間の平均を計測します。

欠陥の存続期間 = バグ起票からバグ解決までの時間

一般的に、欠陥の存続期間は日数を単位とします。たとえば、バグが2022/4/6に検出され、2022/4/23に修正されたとします。この場合、欠陥の存続期間は17日です。

欠陥の存続期間がだんだん短くなっている場合、QAチームが成熟していることを示す強力な材料です。つまり、テストサイクルを重ねるたびにバグ修正にかかる時間が短縮しています。

16.テストケースの有効性

テストケースの有効性はパーセント値として算出され、検出されたバグにおけるテストケースの有効性を表します。つまり、1回のテストサイクルで、QAチームによって実行されたテストケースのうち、いくつがバグを検出できたかを表します。

計算式は単純です:

テストケースの有効性 = (発見されたバグの数/実行されたテストケースの数) x 100

これはテストケースの品質を測る重要なメトリクスであり、テストサイクルを重ねるにつれて徐々に増加するべきです。テストケースの有効性は、QAチームのパフォーマンスを最も明確に示す指標の1つです。

17.欠陥検出漏れ率

欠陥検出漏れ率は、このリストの最初のメトリクスである見逃されたバグ数と似ています。違いは、欠陥検出漏れ率では、UAT(ユーザー受け入れテスト)ステージに持ち越されたバグの数をモニターすることです。そのため、欠陥検出漏れ率の扱いは、見逃されたバグ数に比べればずっと深刻ではありません。

基本的に、欠陥検出漏れ率は、アプリケーションが複数階層のテストを通過した後、UATで見つかったバグの数を反映します。理想的には、潜在的なユーザーが製品に触れる前に、テストケースによってバグが検出されるべきです。

欠陥検出漏れ率は次の式で計算されます:

欠陥検出漏れ率 = (UATで見つかった欠陥の総数/ UATの前に見つかった欠陥の総数) x 100

18.テストケースの生産性

経営層にこのメトリクスをレポートする義務はない場合もあるかもしれませんが、このメトリクスを計測することは、チームに対して現実的な期待値を設定するのに役立ちます。

テストケースの生産性は、特定のスプリント/サイクルでテストケースを作成するのに必要だった作業量を評価します。

テストケースの生産性は次の式で計算されます:
テストケースの生産性 = (テストケース数/1テストケースにつき必要な作業量) x 100

当然ながら、「1テストケースにつき必要な作業量」は厳密な数字ではありません。特定のテストケースは他のテストケースより多くの設計作業を必要とするでしょう。しかし、テスターに質問して妥当な平均値を決めることはできます。このメトリクスは、各サイクルでチームが何を完了できるかについて妥当な感触を提供します。

19.テスト完了ステータス

設計されたテストケースがすべて完了まで実行されるとはかぎりません。成功するテストケースもあれば、失敗するテストケースもあり、中には実行されないテストケースや中断されるテストケースもあります—テスト完了ステータスのモニターは、チーム全体のパフォーマンスを示すKPIの1つです。

いくつかの式の結果を組み合わせてテスト完了ステータスの全体像を表します。

実行済みテストケースの割合 = (実行済みテストケース数/作成済みテストケース数) x 100
未実行テストケースの割合 = (未実行テストケース数/作成済みテストケース数) x 100
成功したテストケースの割合 = (成功したテストケース数/実行済みテストケース数) x 100
失敗したテストケースの割合 = (失敗したテストケース数/実行済みテストケース数) x 100
ブロックされたテストケースの割合 = (ブロックされたテストケース数/実行済みテストケース数) x 100

これらの数字がわかっていれば、QA業務の現況をすばやく判断できます。たとえば、成功したテストケースの割合がブロックされたテストケースの割合よりも低い場合、テストケースの設計またはテスト環境に根本的な問題がある可能性があります。そこで、次のスプリントで結果を改善するためにねらいとするべき問題がわかります。

20.テストレビューの効率

テストケースはバグを警告する可能性があるいっぽう、たとえ数分しかかからないとしても、テスターが警告をレビューする必要があります – しかも、たいていは数分以上かかります。にもかかわらず、ソフトウェアや開発ステージによっては、テストで大量のバグがレポートされる可能性があります。1つ1つをレビューする時間が蓄積されるため、テストレビューの効率を計測する必要があります。

テストレビューの効率 = (レビュー済みテスト数/ レビューが必要なテスト総数) x 100

もちろん、このメトリクスの式は、特定の期間のコンテキストで適用する必要があります。たとえば、7日間のテストスプリントで58個のバグが検出されたが、バグの性質上、レビューして解決に進められたのは45個だけだったとします。この場合のレビューの効率は77%です。

また、このメトリクスはチームのパフォーマンスを測るのによい数値であり、より多くの欠陥をレビューするために何が必要かを明らかにするのにも役立ちます。

結論

QAチームのパフォーマンスを計測することの重要性はいくら強調しても足りません。どんな投資にも言えることですが、QAはSDLCにおける自身の存在意義を説明すため、適切なリターンを示すべきです。さいわいなことに、進化するベストプラクティスに従っているかぎり、QA機能が必要であり有効であることは何度となく証明されています。

上記のQAメトリクスを計測すれば、テストチームのパフォーマンスとテストチームがもたらす絶対的な価値を徹底的に明らかにできるでしょう。

（この記事は、開発元Gurock社の Blog 「Guide to the top 20 QA metrics that matter」2022年10月12日の翻訳記事です。）