QAメトリクスの価値とは何でしょうか? 計測し、分析し、レビューし、結果に基づいて対処することに労力を費やす意味はあるのでしょうか? アジャイル開発手法がもてはやされ、導入が進むにつれて、QAメトリクスは進化し、需要も増えてきました。かつては、実行されたテストの数や成功または失敗したテストの数がQAメトリクスとして計測されていましたが、これらはもはや、QAテストやソフトウェアリリースの品質改善にはあまり役立ちません。

トップQAメトリクスは現実的なビジネスバリューを提供し、ソフトウェアリリースの品質を改善することでカスタマーエクスペリエンスの向上につながる変化をうながします。いくつかの項目を計測して、結果をレビューして、結果から継続的にテストとアプリケーションの品質を改善する、と言うと簡単そうに聞こえます。

QAメトリクスの問題は、多くは主観的であるために定量化が難しいという点です。さらに、QAメトリクスの計測はリソースを必要とします。それでも、QAテストや開発チームのプロセスがどれほど効果的かを知るには、メトリクスが重要です。結局のところ、開始点がどこかという基準なしに改善することは不可能です。アジャイルチームは継続的に改善を実施します。QAおよび開発チームのメトリクスを計測しなければ、改善を始めるためのベースラインがわかりません。 

これは、あらゆるソフトウェア開発組織およびチームに当てはまります。QAメトリクスによって明らかになった問題が無視され続けるなら、アプリケーション品質の改善は起こりません。問題を無視しても、問題はなくなりません。最良のQAメトリクスも、アクションがなければソフトウェア品質を改善することはできません。計測とアクションが組織とソフトウェア開発チームにビジネスバリューをもたらします。

この記事では、ソフトウェア品質の継続的な改善を可能にする、価値あるデータを提供するQAメトリクスの上位5つを挙げます。

QAメトリクス第1位 – ユーザー心理

アプリケーションの品質を測るメトリクスの第1位はユーザー心理、つまりアプリケーションのユーザーエクスペリエンスの質です。カスタマーサポートへの電話、調査、顧客と直接やり取りする製品マネージャーなどとの会話を通じて、顧客からのフィードバックを収集して分析します。顧客がどのように新機能や機能拡張を利用しているかも、以降のスプリント作業で改善するべき他の領域を示唆している可能性があります。顧客のニーズに応える計画を立て、アプリケーションが常にユーザーの求めるワークフローをサポートできるようにします。

ユーザー心理メトリクスは、ユーザーが感じているアプリケーション品質、ユーザビリティ、安定性、ブランド価値のレベルを効果的に測ることができるため、ビジネス全体に価値をもたらします。ユーザー心理を測定するには、顧客へのインタビュー、オンラインまたは対面での調査、あるいは顧客インプットテストセッションなどを利用できます。顧客インプットセッションでは、顧客を招いて直感的なわかりやすさやユーザーエクスペリエンスの質について直接インプットをもらいます。 

QAメトリクス第2位 – 運用で見つかった欠陥

リリース後に運用でレポートされた欠陥は、ソフトウェア品質の継続的な改善を可能にする、価値あるデータを提供するQAメトリクスの第2位です。欠陥の見逃しまたは欠陥検出漏れとも呼ばれるこのメトリクスは、どうして運用中のリリースで欠陥が見つかることになったのかを理解するのに不可欠です。運用中に見つかった欠陥を解析することで、以下のチームまたは組織の機能のうち1つまたは複数に存在するギャップが示されます。

• 要件の変更または範囲のずれ
  • 関連性のある複数のストーリーで、ドキュメント化されていない機能が追加または削除された
  • ドキュメント化されたストーリーまたは要件なしに新機能が追加された
• アプリケーションの特定の領域でテスト ケースの深さまたは幅が不足している
  • バックエンド処理または統合された接続機能のカバレッジが不足している、またはカバーされていない
  • テストのスピードとテストカバレッジの不均衡
• テスト環境と運用環境の基盤の違い

誰でもホットフィックスは避けたいものです。運用環境へのホットフィックスは神経を使い、時間を選ぶものであり、大急ぎで行われることもよくあります。ホットフィックスは、リリースに対するテストの実行が完了した後に、追加の欠陥を呼び込む原因になりがちです。残念ながら、品質の高いカスタマーエクスペリエンスを提供し続けるには、ホットフィックスは避けられません。ビジネスが活力を保ち成功し続けるには、顧客の存在が必須です。アプリケーションを利用しようという顧客がいなければ、ビジネスはなく、ソフトウェア開発チームもありません。

運用で見つかった欠陥は、文字通り、顧客またはサポートチームが欠陥を記録した回数によって計測されます。その他の計測方法としては、リリース後に作成されたホットフィックスまたはパッチリリースを数えます。 

QAメトリクス第3位 – テストケースのカバレッジ

QAメトリクストップ5の第3位はテストケースのカバレッジです。テストケースのカバレッジを計測するとは、テストで使用されるテストケースの品質と内容を分析することを意味します。テストカバレッジを計測することで、すべてのストーリー、要件、受け入れ条件が1つ以上のテストケースでカバーされていることが保証されます。多くのソフトウェア組織は、テストカバレッジと実行されたテストの数を同一視するという間違いを犯しています。実行されたテストの数はマーケティング目的でのみ役に立ちます。実行されたテストの数はテストの妥当性や要件に対するカバレッジを意味しません。

テストカバレッジの質、深さ、幅広さを計測するには、テストケースをレビューしてユーザーストーリーおよび受け入れ条件にマッピングします。たとえば、テスト管理ツールを使用してテストケースを要件またはユーザーストーリーとリンクします。通常、テスト管理ツールはストーリーID、要件ID、ドキュメントに直接リンクする機能を備えています。そのような機能がない場合、テストケースの説明、サマリー、再現手順にストーリーIDまたは要件番号を手動で追加してマッピングすることもできます。手動でのリンクは追跡が難しくなりますが、ユーザーストーリーまたは要件に対するテストケースのカバレッジを比較するのに必要な要件との関連付けを可能にし、すべての機能が有効なテストケースによってカバーされているであろうことを保証できます。 

テストケースおよびユーザーストーリーをレビューし、すべてのストーリーおよび受け入れ条件がテストケースで正しくカバーされていることを確認します。トレーサビリティが確保されていれば、すべての機能に対して適切なテストカバレッジを保証できます。いっぽう、有効なテストケースがなければ、欠陥が気づかれない可能性があります。

QAメトリクス第4位 – 複数スプリントにわたる欠陥

QAメトリクスの4位と5位は関連しています。複数スプリントにわたる欠陥の計測が第４位に来るのは、このメトリクスが開発ライフサイクル全体を通じた欠陥の存続期間を計測するからです。リリース前のコードに欠陥が長く存在しているほど、それが最終的な製品リリースにも存在する確率は高くなります。

一般的に、別のスプリントに欠陥がずれこむ理由は、ストーリーを引き受けすぎていたり、割り当てられたストーリーをスプリント中にすべてデリバリーしていなかったりするからです。ストーリーを完了ステータスに移動させるには、開発に加えて単体テスト、機能テスト、統合テストを含むすべてのテストが完了している必要があります。時間的制約のためにスプリント終了時にストーリーが完全にテストされていない場合、欠陥が残存します。後続のスプリントまで欠陥が修正されない場合、欠陥の複雑さと範囲が増大しがちです。

複数のスプリントにわたる欠陥を計測するには、スプリントから別のスプリントへ移動された欠陥ストーリーの欠陥IDを文書化します。その後、別のスプリントに繰り越された欠陥をまとめ、別のスプリントに繰り越されたフィーチャーストーリーも追加します。これらを比較し、同一の問題であるか、原因が同じ別個の症状であるかを判断します。同じ欠陥が運用で発見される場合、または欠陥の数が増え続けている場合、継続的プロセス改善およびアジャイルの一部としての欠陥のずれこみに対処します。

QAメトリクス第5位 – 割り当てられたストーリー vs. デリバリーされたストーリー

先ほども言ったとおり、QAメトリクス4と5は似ています。同じ欠陥が後に運用で発見されがちであることから、複数のスプリントで発生する欠陥のメトリクス数のほうにより高い順位が付けられています。  割り当てられたストーリーに対するデリバリーされたストーリーの計測は、機能拡張、欠陥、または欠陥修正を含むすべてのストーリータイプに適用されます。

割り当てられたストーリーとデリバリーされたストーリーを計測することで、複数のストーリーが関連しているにもかかわらず、揃ってデリバリーされていない場合に発生するコードまたは機能のギャップを知ることができます。統合テストは、2つのストーリーが互いに依存または関連しているが、一度にデリバリーされていない場合に発生する欠陥を発見できる場合があります。 

割り当てられたストーリーに対するデリバリーされたストーリーを計測するには、すべてのストーリーの進捗を追跡します。スプリント終了時に、どのストーリーが割り当てられたがデリバリーされていないかを記録し、デリバリーされたストーリーと比較します。これらのストーリーは互いに依存していたり、関連していたりしないでしょうか? 依存または関連している場合、いっぽうのストーリーがデリバリーされていないとき、互いをサポートするコードがないという欠陥が存在する可能性があります。 

別のスプリントにずれこんだストーリーの数やタイプを計測すると、計画の問題やストーリー開発の問題がわかります。後のスプリントに持ち越されたストーリーの数が増え続けている場合、リリースに機能が含まれないリスクが高くなります。

QAメトリクスの真価を得る

テストとアプリケーションの品質向上を目的として、これらQAメトリクストップ5の計測を始める前に、QAチームのゴールを明確にします。アジャイルチームでは、QAテスターだけではなく、チーム全体がアプリケーションの品質に責任を持ちます。QAテストのゴールは、単にリリースに存在するすべての欠陥を見つけることではありません。多くのソフトウェア開発スケジュールの中では、それは不可能です。QAテストを改善する理由は、組織によって十分なアプリケーション品質として定められた水準をアプリケーションが満たしているという保証を提供するためです。

QAテストの特質として、スピードとバリューのバランスがあります。QAメトリクスによって、チームにはスピードがあるが品質が低いと示されたとすれば、バランスは崩れています。アプリケーションの品質と同様に、スピードはアプリケーションとビジネスの鮮度を保つのに重要です。

QAメトリクスを使用してユーザー心理、運用時の欠陥、テストケースカバレッジ、複数スプリントにわたる欠陥、割り当てられたがデリバリーされなかったストーリーの数を計測することで、アプリケーションの品質とスピードのバランスを含む有用な全体像が明らかになります。アプリケーションの品質を改善し、ベストな結果を目指して継続的改善に取り組むために、計測、分析、レビューを実施しましょう。

Amy E Reichert – QAテスト、アジャイル、技術動向を主としたさまざまな話題を専門とするフリーランスのライター。AmyはERP、ヘルスケア、業務管理分野でQAエンジニア/アナリストとして23年の経験があります。また長年にわたりテストケースおよびテストプロセスを開発し、多様でインクルーシブなチームのリーダーを務め、モバイルおよびウェブアプリケーションのテストに従事した経験もあります。

（この記事は、開発元Gurock社の Blog 「The top 5 agile QA metrics to improve your testing」2022年10月17日の翻訳記事です。）

関連する製品

テスト管理ツール TestRail

テストケースの管理やテスト結果の記録、チームでの情報共有など、Excelを使ったテスト管理の業務に限界を感じていませんか？TestRailはシンプルで使いやすいUIを提供し、テストにかかるさまざまな管理コストの削減に貢献します。

■ TestRailの特長 ■

• テストにさまざまな情報を関連づけて一元管理
• Webブラウザー上でテストケースを簡単に入力や編集可能
• テスト実施の準備と結果の共有が容易
• 進捗や比較などのレポートを提供
• 要件 / 課題管理ツールやテスト自動化ツールと連携

日本国内では、テスト管理にExcelを使っていたお客さまからの乗り換えが多く、Web上で完結するテスト管理を実現されています。

TestRail でテスト管理のお悩みを解決しませんか？