テストケースに優先順位を付けるためのテクニックとメトリクス

Hannah Son著

変化の速いソフトウェアエンジニアリングおよび開発の世界では、時間は貴重です。高品質のソフトウェアをより速くデリバリーしなければならないというプレッシャーは増すいっぽうであり、テストケースに優先順位を付けることがソフトウェアテストプロセスにとって不可欠になっています。

この記事では、テストケースへの優先順位付けの原則、テストケースに優先順位を付ける際に考慮するべき要因、テクニックなどについて説明します。

テストケースの優先順位付けとは
テストケースの優先順位付けが重要な理由
テストケースの優先順位付けで考慮するべき要因
テストケースの優先順位付けのテクニック
効果的なテストケース優先順位付けおよびメンテナンスのベストプラクティス
優先順位を付けたテストスイートの有効性を計測する方法
まとめ
関連する製品
- テスト管理ツール TestRail
  - ■ TestRailの特長 ■

テストケースの優先順位付けとは

テストケースの優先順位付け (Test case prioritization、TCP) とは、テストケースの重要性、機能、ソフトウェアに対する潜在的な影響などに基づいてチームが実行するテストケースを編成することを意味します。

テストケースの優先順位付けによって、適切なテストを適切な時に確実に実施できます。テストケースの優先順位付けとしては、たとえば重要な機能を最初にテストしたり、特定のテスト手法 (たとえばブラックボックステストなど) を他の手法より優先したり、長いテストの前に短いテストを実行したり、また、リスクをより早く表面化させ、QAチームの時間を最大限に活用できるようにする方策が考えられます。

テストケースの優先順位付けは、手動で行われるテストにも、自動で行われるテストにも適用されますが、その方法は手動テストか自動テストかで多少異なる可能性があります。たとえば、自動テストに関しては、CI/CDパイプラインで特定のテストを他のテストよりも前にスケジュールすることで優先順位を付けるいっぽう、手動テスト (受け入れテスト、探索テスト、またはその他の機能テスト) については、単純に優先順位の高いテストを選択して先に実行することで優先順位を付ける場合があるでしょう。

テストケースの優先順位付けが重要な理由

テストケースに優先順位を付け、最も効率的な順序で実行することは、開発ライフサイクルのできるだけ早い段階でソフトウェアのバグを検出するのに重要です。

テストケースの優先順位付けによって、より戦略的にテストすることが可能になり、特に時間とともにアプリケーションの複雑度が(したがってテストケースの数も)増していく状況で、チームがテストに利用できる時間をバランスよく配分できます。

テストケースの優先順位付けはどの開発手法においても重要ですが、リリースのペースに合わせるためにできるだけ早くデバッグを開始する必要があるアジャイル開発プロセスを採用している場合はとりわけ重要です。

テストケースの優先順位付けで考慮するべき要因

「テストケースの優先順位付け」というトピックに関してIEEEによって公開されている多数の実践的研究や学術論文が証明しているとおり、テストケースの優先順位付けは高度な解析、アルゴリズム、そして欠陥検出率などのメトリクスを含む複雑なプロセスにもなりえます。

実際、テストケースに優先順位を付けるには、開発しているソフトウェア、重要な機能、潜在的なリスク、ビジネス上の優先順位を理解している必要があるのが普通です。以下の要因を考慮することで、QAエンジニアはより効果的にテストケースの優先順位付けに取り組むことができます。

テスト対象ソフトウェアの重要な機能を特定する

QAエンジニアにとって、作業対象のソフトウェアの重要な機能を理解することは必須です。それらはユーザーやビジネスにとって最も重要な機能です。たとえば、Eコマースアプリケーションであれば、購入手続きは収益に直接的な影響を与えるため、重要な機能です。

リスクを評価する

潜在的なリスクとその影響度を評価することは、テストケースの優先順位付けにおいて重要です。通常、リスク評価には、識別されたリスクが起きる可能性とリスクが起きたときの潜在的な影響を分析することが必要です。

リスクを測定する方法の１つは、欠陥の傾向(fault proneness)、欠陥の深刻度(fault severities)などの技術的要因およびコードの変更を考慮し、各テストケースに関連する潜在的なリスクを評価することです。

欠陥の傾向は、単に欠陥の数を確認するだけではありません。欠陥の傾向に基づいてテストケースの優先順位を付ける場合、ソフトウェアの過去のバージョンで、要件の欠陥の確率がどれほど高かったかに応じて優先順位を割り当てます。

Association for Computing Machineryによれば、「オブジェクト指向クラスの欠陥の傾向は、クラスがどの程度欠陥を発生させやすいかを示します」。また欠陥の深刻度は、「テスト対象ソフトウェアプラグラムに対してどれほど大きな影響を持つかを意味します。深刻度が高いほど、バグ/欠陥がシステムの機能により大きな影響を与えます。」

より漠然とリスクを評価することもできます。たとえば、機能はどれほど複雑か？機能はどれほど頻繁に使用されるか？機能はどれほど重要か？といった質問は評価の役に立ちます。欠陥が顧客にどれほど影響を与えるかを考慮します。欠陥はどれほど目につくか？欠陥を修正するのはどれほど難しいか？この欠陥は収益、顧客の繋ぎ止め、顧客ロイヤリティなどに影響を与えるか？こういった質問を基に、各テストケースのリスクおよび影響度に(定性的評価または数値として)値を割り当てます。

ビジネス上の優先順位と整合性を取る

テストケースに優先順位を付ける際は、顧客の要求と好みを意識します。たとえば、特定の顧客ニーズに応える新機能をリリースする場合、その機能に関連するテストケースを優先します。

テストケースの優先順位付けは、ソフトウェア開発プロジェクトの全体的なビジネス目標との整合性を取る必要があります。

テストケースの優先順位付けのテクニック

テストケースの優先順位付けは、QA エンジニアが優先度の高いテストケースを識別し、欠陥の検出とリスクのカバーに関して最も大きな可能性を持つテストケースに注力するのに役立ちます。次のテクニックを利用してテストに優先順位を付けると、最も影響の大きい領域に確実にテストの労力を集中することができます。

リスクベースの優先順位付け

テストケースの優先順位付けのコンテキストでは、リスクとは、バグが発生する可能性です。リスクベースの優先順位付けテクニックでは、リスクを分析して、故障した場合に望ましくない問題を引き起こす可能性がある領域を特定し、リスクが高いテストケースをリスクが低い他のテストケースよりも優先します。

リスク分析を進める際に次の手順が役立ちます。

リスクを判断するのに役立つ次の質問を自問します。
- 機能はどれほど複雑か？
- 機能はどれほど頻繁に使用されるか？
- 機能性にとってどれほど重要か？
- 欠陥を修正するのはどれほど難しいか？
- 欠陥はどれほどユーザーに影響を与えるか？
- 欠陥はどれほど利益に影響を与えるか？
潜在的な問題は何か、また各問題が発生する可能性はどの程度かを検討します。

各問題の影響の重大さを計算します。

履歴ベースの優先順位付け

履歴ベースの優先順位付けは、ソフトウェアモジュールの欠陥の傾向と欠陥の深刻度を考慮し、テストケースに優先順位を付けます。このアプローチは、以前のテスト実行結果や欠陥検出率などの履歴データを使用してテストケースに優先順位を付けます。このアプローチを採用すると、過去に欠陥を検出したテストケースまたは欠陥検出率が高いテストケースにより高い優先順位が与えられます。

要件ベースのカバレッジ
要件ベースの優先順位付けは、最も重要なテストケースまたはソフトウェアの機能性に大きな影響を与えるテストケースを持つ要件を優先します。このテクニックを利用すると、テストケースに優先レベルが割り当てられ、より優先レベルが高いテストケース(最も重要なテストケース)が優先レベルが低いテストケースよりも先に実施されます。

カバレッジベースの優先順位付け

カバレッジベースの優先順位付けでは、コードカバレッジに基づいてテストケースに優先順位を付け、コードの最も重要な部分が最初にテストされるようにします。この優先順位付けテクニックは、多くの場合、単体テストまたは自動テストに関して使用されます。カバレッジベースの優先順位付けのサブテクニックには次のようなものがあります。

合計ステートメントカバレッジ優先順位付け: カバーするステートメント数の合計に基づいてテストケースに優先順位を付けます。たとえば、T1が7ステートメントをカバーし、T2が4ステートメント、T3が15ステートメントをカバーする場合、優先順位はT3、T1、T2になります。
合計ブランチカバレッジ優先順位付け: ブランチカバレッジは、アプリケーションのすべての実行パスがテスト対象になっているかどうかを表します。テストケース優先順位付けのコンテキストでは、ブランチカバレッジとは、条件文の可能な結果に対するカバレッジを指します。

バージョンベースの優先順位付け

バージョンベースの優先順位付けは、ソフトウェアの最近のバージョンで追加または変更されたコードに関連するテストケースを重視します。最近のコードの変更によって影響を受ける領域を対象とする回帰テストケースを優先することで、ソフトウェアの安定性を保証します。

コストベースの優先順位付け

コストベースの優先順位付けでは、テストケースの実行時間、リソース、テスト環境のセットアップなど、各テストケースを実行するためのコストを考慮します。このアプローチでは、最も低いコストで最も高い利益が得られるテストケースを優先します。

効果的なテストケース優先順位付けおよびメンテナンスのベストプラクティス

適切に行えば、テストケースの優先順位付けはテストプロセスが生み出す価値を最大化します。以下は、効果的なテストケース優先順位付けのためのベストプラクティスです。

開発者および営業関係者と協力する

優先順位付けに開発者、QAエンジニア、営業関係者(組織にとって意味がある場合は)を参加させ、ソフトウェアの要件およびリスクを総合的に理解できるようにします。コラボレーションが活発になれば、QAエンジニアがテスト時に対処するべき重要な機能や潜在的問題を識別するのに役立ちます。

明快なコミュニケーションを確立する

チームメンバー間のコミュニケーションチャネルを確立し、テストケース優先順位付けに関する洞察、懸念、提案を共有します。ソフトウェアの要件、リスク、優先順位に関する認識が共有されていれば、テストプロセスの合理化に役立ち、誰もが同じ前提に立つことができます。

変化する要件に合わせて優先順位を調整する

ソフトウェア開発の進行に伴って、コードの変更、レポートされたバグ、要件の変更などの新しい情報に基づいてテストケースの優先順位を再評価し、調整する必要があることを認識しましょう。定期的にテストケースの優先順位を調整し、変化に対応することで、テストスイートを最新の状態に保ち、テスト作業がプロジェクトの目標と合致するよう保証します。

優先順位付けテクニックの有効性を継続的に評価する

カバレッジベース、履歴ベース、リスクベースのアプローチなど、テストケース優先順位付けテクニックの有効性を定期的に評価します。欠陥検出率、実行時間、平均欠陥検出率(APFD)値などのQAメトリクスを使用して、優先順位付けがうまくいっているかを評価し、必要に応じて調整します。

回帰テストのテストケースに優先順位を付ける

回帰テストは、コードの変更が新しい欠陥を入り込ませたり、既存の機能に悪い影響を与えたりしていないことを確認します。テストスイートが大きくなるにつれて、回帰テストケースに優先順位を付け、欠陥の検出を最大化しながらテスト実行時間を最小化することが重要になります。

重要な領域、リスクの高い領域、鍵となるビジネスドライバーに関連する回帰テストの実行に注力しましょう。また、複数システムの統合に依存している領域や特に脆弱な領域など、過去に欠陥が検出された領域の回帰テストを実行することも重要です。

優先順位を付けたテストスイートの有効性を計測する方法

テストスイートの有効性の計測は、優先順位付けがうまくいっているかを判断し、ベンチマークを設定し、データに基づく決断を下すのに欠かせません。以下は、QAエンジニアが優先順位付けの影響を計測し、データに基づいてアクションを起こし、テストスイートの有効性を改善する3つの方法です。

1.有効性を計測するメトリクスを定義する

優先順位を付けたテストスイートの有効性を計測するには、妥当なメトリクスを定義する必要があります。テストスイートの有効性を計測するためのメトリクスには次のようなものがあります。

テストカバレッジ

テストカバレッジは、アプリケーションのすべての要件のうちどの程度がテストによってカバーされたかを表します。テストカバレッジが低い場合、テストされていない要件があり、未検出のリスクがあるコードをリリースする確率が上昇することを意味します。

テストカバレッジ = (テストケースにマップされた要件の総数/要件の総数) x 100

**画像:** TestRailでリアルタイムのメトリクスおよび統計値を参照し、参照のカバレッジなどの高度なトレーサビリティおよびカバレッジレポートを生成

欠陥検出率

欠陥検出率メトリクスは、テスト中に見つかった欠陥の数を計測します。欠陥検出率が高いことは、テストスイートが効果的に欠陥を検出していることを表します。

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

要件単位で見つかった欠陥の数を計測します。このメトリクスは、アプリケーション内でもっとテストが必要な領域を識別し、特定の要件が他の要件よりもリスクが高い場合、それを明らかにできます。このメトリクスは、製品チームが機能をリリースするべきかどうかを判断するのに役立ちます。

テストのコスト/テスト時間

これらのメトリクスは、テストスイートを実行するのに必要な時間を計測します。より具体的には、テスト時間メトリクスは、チームまたはQAエンジニアが、ソフトウェアの品質に影響を与えることなく、どれほどすばやくテストを作成し、実行できるかを明らかにします。テストケースの優先順位付けが改善されると、コストが削減されるはずです。これは、多くのQAチームが特定の予算内で活動し、支出予定額をつぶさに記録して、予算を正当化しなければならない状況では重要です。

変更欠陥率

DORA レポートによれば、変更欠陥率は、運用に入った後またはエンドユーザーにリリースされた後に欠陥につながる変更を特定するメトリクスです。

2.メトリクスの追跡と分析

妥当なメトリクスを識別し、定義したら、定義済みのメトリクスに関するデータを収集するプロセスを実装する必要があります。選択したメトリクスのデータを収集したら、データを解析し、優先順位を付けたテストスイートの有効性を評価します。

以下は、QAメトリクスを解析してテストケースに優先順位を付ける際に注意するべき重要事項です。

QAメトリクスは絶対ではなく指標です。
単一のQAメトリクスだけに頼って製品の品質を評価しないようにします。
QAチームメンバーは、どのメトリクスが追跡され、どのように計算され、計測されるかを理解する必要があります。
アプリケーションのもっとテストが必要な領域やテストを減らしてもよい領域を識別することに解析の労力を集中させましょう。

予測と経過時間の記録、複数のテストラン、構成、マイルストーンにわたる結果の比較、要件、テスト、欠陥のトレーサビリティおよびカバレッジレポートの取得などにテスト管理ツールを活用できます。

TestRailを使ってリアルタイムでテストデータを可視化する方法や、レポートテンプレートを使ったテストカバレッジとトレーサビリティのチェックについては、「TestRailでテスト活動のKPIを計測する」もご一読ください。

3.分析を基に調整する

データ収集と分析に基づいて改善可能な領域を識別し、必要に応じてテストスイートの優先順位に調整を加えることが欠かせません。

たとえば、アプリケーションの重要な領域でテストカバレッジが低い場合、その領域のテストを優先する必要があります。いっぽう、テストのコスト/時間メトリクスが高い場合、リスクを顕著に増やすことなくテストを減らしたり、スピードアップしたりできる領域を識別する必要があります。

分析に基づいて行うことができる調整には、以下のようなものがあります。

テストカバレッジが低い場合、より多くのテストケースを追加し、不足している領域をカバーします。
欠陥検出率が低い場合、テストケースを見直して欠陥を効率的に発見できるようにします。一般的に、欠陥検出率が高いほど、ソフトウェアがエンドユーザーにリリースされる前にQAエンジニアおよびテスターが多くの問題を検出して対応していることを表すため、望ましいことです。
テストのコスト/時間メトリクスが高い場合、テストプロセスを最適化したり、より多くのテストを自動化したりすることを検討します。
変更欠陥率が高い場合、優先順位付け戦略を見直して、リスクの高い領域を最初にテストするようにします。

優先順位が付けられたテストスイートの有効性を計測することは、アプリケーションの重要な領域にテストを集中させるために欠かせません。妥当なメトリクスを定義し、テストデータを追跡して分析し、結果に基づいて調整を行うことで、テストチームはテストスイートの有効性を改善できます。

まとめ

アジャイル環境で作業する場合、リリースのペースに遅れることなくリスクを最大限にカバーできるよう、より戦略的にテストし、実行するテストに優先順位を付けなければなりません。テストケースの優先順位付けは、テストチームが最も重要なテストケースから実行し、欠陥検出およびリスクカバレッジを最大化するのに役立ちます。

テストケースの優先順位付けテクニックおよびアルゴリズムを採用することで、QAエンジニアはテストプロセスをカスタマイズし、ソフトウェア開発プロジェクト全体の品質を改善できます。

**画像:** TestRailの詳細なレポートは、容易に複数のテストラン、構成、マイルストーンにわたる結果を比較し、予測と経過時間を正確に記録し、コンプライアンス要件を満たすトレーサビリティおよびカバレッジレポートを取得するのに役立ちます。

最適化を実現するためのこれらのテクニックに加えて、テストケースの優先順位付けを自動化するのに役立つさまざまなツールが存在します。テストケースの優先順位付けと整理を可能な限り容易にし、テストケースをより素早く作成し、テストケースを1か所で構成できるよう設計されたテスト計画ソフトウェアとしてのTestRailをチェックしてください。ぜひTestRail 評価版をお申し込みください。

（この記事は、開発元Gurock社の Blog 「Test Case Prioritization Techniques and Metrics」2023年8月4日の翻訳記事です。）