テスト自動化の成功度を測るための重要なメトリクス
テストには莫大な費用がかかります。エンジニアリングの労力、ライセンス料、そしてテスト時間などです。その費用に見合うだけの効果があるのでしょうか？どうすれば確信が持てるのでしょうか？
たとえば企業では、欠陥を早期に発見し、より早くリリースするために、テスト自動化に多大な投資を行っています。このプロセスは通常、熟練したテスターの雇用や自動化チームの結成、そして最近利用できるようになった多くのツールやフレームワークによる自動化の構築から始まります。
フレームワークの構築と設定にかなりの時間が費やされた後、チームはテストを CI/CD (継続的インテグレーションとデリバリー) パイプラインに統合し、チェックインされたコードに基づいて定期的にテスト実行をします。ほとんどのチームは、これが自動化の作成と実行の全サイクルの終点であるという結論に達します。
しかし、テスト自動化に重要な側面がもう1 つ残っています。チームは、自動テストの成功を測定するために時間と調査を費やす必要があります。多くの場合、チームはプロジェクトで何をしたかを知っていますが、終了すると疲れ果ててしまい、プロジェクトから何を得られたかまでは考えません。
ここでは、チームが価値を生み出すために使用するようなメトリクスについて調べてみましょう。
自動化を成功させるための優れたメトリクス
ここでは、プロジェクトとチームの状況に応じて、考慮すべき適切なメトリクスをご紹介します。これらのメトリクスは、自動化の成功を測定する際のあいまいさを減らし、それによって意思決定に役立つより多くの情報を提供します。
経営者やビジネスサイドの同僚と話すときは、特定のメトリクスを「KPI」として定義しましょう。なぜなら、「Key Performance Indicator (重要業績評価指標)」はその界隈で戦略を立てるときに好んで使われる単語だからです。
完了したテストの数
単純な集計には難しい点が多くありますが、そのうちのいくつかをご紹介します。完了したテストの総数とその結果 (合格、不合格、結論なしなど) は基本的な集計なので、ほぼ常に保存する価値があります。これらは、自動テストと非自動テストの両方、およびユーザーインターフェース (UI) とアプリケーションプログラミングインターフェース (API) の両方の要件について合計することが重要です。たとえば、自動化プロジェクトによって、1 日または 1 週間に完了したテストの総数が減少した場合、ほぼ確実に何かが間違っています。
いくつかのメトリクス、たとえば削減された時間や発見された欠陥の割合などは、「スコアをつける」のが簡単であることに注目してください。つまり、多ければ多いほど良く、組織がKPIとして採用しやすいものです。対照的に、完了したテスト数の時間経過によるグラフは、この種の「成績」ではありません。これらのカウントのポイントは、単に大きなスコアを積み上げることではなく、より深いストーリーを示唆することです。完了したテストの数は、「なぜ手動テストでは、3週目、4週目に突然欠陥が見つからなくなったのか」というフォローアップの質問につながる点で価値があります。この傾向が続く場合、1つの欠陥を発見するために 20週目に何回テストを実行する必要があるのでしょうか？根本的な原因を共有する欠陥のレポートを管理する良いシステムはありますか？
削減されたテスト時間
自動テストを構築する主な理由の1つは、貴重な手動テストの労力を削減することです。自動テストが単調なテスト作業を繰り返す間、テスト担当者は、より重要で優先度の高い作業に集中し、アプリケーションの調査に時間を費やし、自動化が困難でクリティカルシンキングを必要とするモジュールをテストできます。
「削減されたテスト時間」は、チームに提供された価値を評価するための良いメトリクスです。たとえば、2週間のスプリントで、自動テストによって手動テストの労力が2日間から4時間に短縮されれば、それはチームと組織にとって大きな利益であり、コストの削減につながります。したがって、このような計測を追跡し、共有すべきです。
自動テストの不安定さ
仮にチームが堅牢な自動化フレームワークを構築するのに4ヶ月を費やしたとして、実際に欠陥を発見するために自動テストを使用する時間よりも、その維持に多くの時間がかかるとしたら、その取り組み全体が無駄になってしまいます。意外なことに、これはチームでよくある問題です。テストが不安定で、複数の要因で失敗し続けるのです。その結果、チームは自動テストを信用しなくなり、最終的には手動での機能テストに戻ることを決意します。
少数のテストから開始し、継続的に実行していく中で、不安定なテストを特定し、それらを安定したテストから分離することが重要です。この方法は、自動テストの価値を高めるのに役立ちます。
軽減されたリスクの数
テストは、リスクに基づいて優先順位を付ける必要があります。リスクとしては、ビジネスに影響を与える予期せぬ出来事、アプリケーションの欠陥が発生しやすい領域、あるいはプロジェクトに影響を与える可能性のある過去や未来の出来事が考えられます。
リスクとの関連で自動化の成功を測定する良いアプローチは、優先順位の高いものから低いものへとリスクをランク付けすることです。そして、リスクの優先順位に基づいてテストケースを自動化し、自動テストによって軽減されたリスクの数を追跡します。
EMTE (同等の手動テスト工数)
EMTE (Equivalent Manual Test Effort：同等の手動テスト工数) は、ソフトウェアの品質保証 (QA) における「古典的な」概念であり、今でも広く議論されています。 EMTE は主に、「自動化プロジェクトを開始する前よりも開始した後の方がうまくいっているか?」といった質問に答えるためのものです。
カバレッジ
カバレッジは、「多ければ多いほど良い」という単純な解釈ができるように思えますが、カバレッジの価値の多くは、時間をかけて注意深く観察することにあります。ソース行のカバレッジと要件数のカバレッジを区別してください。自動テストと手動テストがそれぞれどのようなレベルのカバレッジを扱うとしても、それらを合わせて 100% のカバレッジを得られるようにしてください。
要件カバレッジのスコアは、ユーザーストーリーに直接関連しています。ユーザーストーリーの観点から、ビジネスチームメイトに対してカバレッジ結果を強調しましょう。
いくつかの技術的なメトリクスは、「テストが特定の欠陥を発見する確率はどの程度か？」というアイデアを実現するためのものです。この 1 つのアイデアを測定するために、微妙に異なる公式が使用されています。迷ったときは、チームや組織が以前に使用したことのある特定の定義を選択すると、予期せぬ出来事を最小限に抑えることができます。
自動化されたフレームワークまたはテストの使いやすさ
チームはしばしば、自動テストが、メンテナンスの手間が少なく、誰でも簡単に実行できる必要があり、シンプルで分かりやすいコードであり、テストの成功と失敗・ログ・ダッシュボードやスクリーンショットなどの視覚的な分かりやすい情報を提供する必要がある、ということを忘れがちです。使いやすさを示すこのような要素の組み合わせは、自動化の取り組みが成功したことを強く示唆します。このレベルでは「使いやすさ」は主観的なメトリクスですが、「親しみやすさ」について考えると、テストがチームに与える影響について多くの情報が得られます。
これらすべてのメトリクスは、プロジェクトの文脈に基づいて適用する必要があります。どんなプロジェクトにも一様に適用できるものではありません。しかし、恣意的で単純な数字や労力ではなく、自動テストの価値に焦点を当てるよう、チームの考え方を変えるのに役立ちます。
自動化の成功に関する誤解を招くメトリクス
自動化の測定は、非常に議論の多いテーマです。メトリクスは、組織や個人によってさまざまな役割を果たし、その選択も多岐にわたります。ただし、よく知られたメトリクスの一部には深刻な欠陥があります。上記のようなメトリクスを慎重に検討するとともに、メトリクスの弱点について少し考えてみるのも健全な方法です。メトリクス プログラムは何がうまくいかないかを敏感に察知する練習だと考えてください。以下のメトリクスは、チームが追跡する最も一般的なメトリクスであり、自動化を評価する上で有用なものではありません。
自動化されたテストケースの数
これは、チームが自動化の成功を誤って測定する最も一般的な方法の1つです。一定数の自動テストがあれば、自動化の取り組み全体が成功したと思い込んでしまうのです。
これは、プロジェクトに対する投資とそのリターンを混同してしまうという、前述した間違いの典型的な例であることに注意してください。自動化されたテストケースの数は「得られた価値」よりも「費やされた労力」についてより多くを示しています。
さらに、粗雑なカウントは必ず品質の区別を曖昧にします。たとえば、100個のテストケースから始まるテストスイートがあるとします。プロジェクトでは、そのうちの90個を自動化します。これは確かに 90% に相当しますが、自動化によって人間の労力の 90% が削減されるとか、エラーの 90% が自動テストで発見されるとか、そういった確証はどこにもありません。自動テストとは、自動化するのは最も簡単ですが、最も情報が少ないものかもしれません。また、人間が実行するテストよりも、エラーを検出する可能性が高いかもしれません。このように、単純なカウントは高度な解釈を必要とします。
発見された欠陥の数
自動化スクリプトによって検出された欠陥の数を成功の尺度として使用することも、慎重に解釈する必要があります。欠陥の数は誤解を招きやすく、チームに誤った達成感を与えます。
たとえば、自動化スクリプトで10件の欠陥が見つかった場合は開発者が正しく仕事をしなかったという可能性があり、0件の場合は自動化スクリプトが有効でなかったという可能性があります。これらの結果を解釈する方法は複数あります。
検出された欠陥の数と自動化されたテスト ケースは、さまざまな解釈が可能です。慎重に分析しなければ、自動テストが提供する真の価値から誤解を招くような目標やベンチマークへと、チームの考え方を容易に誘導してしまうでしょう。
フィードバックループの繰り返し
もちろん、より大きなビジネス目標をサポートするために、特定のメトリクスを選択し、他のメトリクスを除外することもできます。優れたメトリクスの選択は、自動化プロジェクトが成功したかどうかを判断し、将来の自動化プロジェクトの指針とするのに役立ちます。時間が経つにつれて、特定のメトリクスが実際にどの程度これらの役割を果たすかについて、より多くを学ぶことができ、選択をさらに更新し、洗練させることができるでしょう。特定のシステムやプロセスよりも重要なのは、システムやプロセスを改善し洗練させる習慣を身につけることです。
いくつか具体的なメトリクスを選び、比較的小さくとも具体的な自動化プロジェクトを立ち上げ、それがどのように機能するかを確認し、日々改善を続けましょう。サイクルを 2、3 回繰り返すうちに、ソフトウェアの品質が格段に向上し、以前のやり方に戻るのが苦痛に感じられるようになるはずです。
（この記事は、開発元 Ranorex 社 Blog 「Key Metrics for Measuring Test Automation Success」2021年9月17日の翻訳記事です。）
