テストケースと優先度の定義

テストの対象を決定し、テストケースを定義し、優先順位を付けます。

Ramona Schwering

前回の投稿では、テスト戦略、アプリケーションのテストに必要なテスト数、リソースに留意しながら最も信頼できる結果を得るために最適なアプリを見つける方法について学習しました。ただし、これはテストすべき量のアイデアに過ぎません。その場合でも、テスト対象を正確に判断する必要があります。次の 3 つの基準は、テストの内容を理解し、どのテストの種類と詳細レベルが最適かを判断するのに役立ちます。

  1. 自分のハッピーパスを大切にする。これは、アプリケーションの最も一般的または主要なユーザー ストーリーで、ユーザーはエラーにすぐに気づくでしょう。
  2. 詳細レベルは慎重に決定します。ユースケースが脆弱な場合や、エラーによって大きな損害が発生する可能性がある場合は、詳しく説明します。
  3. 可能であれば、上位のエンドツーエンド テストよりも下位レベルのテスト（単体テストや統合テストなど）を優先します。

この記事の残りの部分では、これらの基準と、テストケースを定義する際の基準の適用方法について説明します。

テストケースとは

ソフトウェア開発において、テストケースとは、ソフトウェア プログラムやアプリケーションの有効性を確認できるように工夫された一連のアクションや状況のことです。テストケースの目的は、ソフトウェアが計画どおりに動作し、すべての機能が正しく動作することを確認することです。ソフトウェアのテスターやデベロッパーは通常、ソフトウェアが指定された要件と仕様を満たしていることを保証するために、これらのテストケースを作成します。

テストケースを検証しています。

テストケースを実行すると、ソフトウェアは一連のチェックを実行して、目的の結果が生成されることを確認します。それと同時に、テストは次のタスクを実行します。

  • 検証。ソフトウェアがエラーなく機能することを徹底的にチェックするプロセス。作成されたプロダクトが、必要な機能面以外の要件をすべて満たし、意図した目的を首尾よく達成しているかどうかを判断することが非常に重要です。その答えは「プロダクトを正しく構築できているか」です。
  • 検証。ソフトウェア プロダクトが必要な標準または大まかな要件を満たしていることを確認するプロセス。これには、実際の商品が期待される商品と一致しているかどうかを確認することが含まれます。基本的には、「ユーザーの要件に適したプロダクトを構築しているか」という問いに答えます。

プログラムが期待した結果を得られなかったとします。この場合、テストケースはメッセンジャーになります。そのため、失敗した結果が報告されるため、デベロッパーまたはテスターは問題を調査して解決策を見つける必要があります。 チェックとアクションは、テストの種類に関係なく、コンピュータがたどるパスと考えてください。チェックに使用される入力データまたは条件のグループは、「等価クラス」と呼ばれます。テスト対象システムから同様の動作や結果が得られるはずです。テスト内で実行される具体的なパスはさまざまですが、テストのアクティビティとアサーションと一致している必要があります。

テストパス: 一般的な種類のテストケース

ソフトウェア開発におけるテストケースとは、特定の動作が想定され、テストされるコード実行シナリオです。通常、テストケースの作成元には 3 つのシナリオがあります。

ハッピーパス。

1 つ目は最もよく知られているもので、すでに利用していることでしょう。これがハッピーパスであり、「ハッピーデイ シナリオ」または「ゴールデンパス」とも呼ばれます。機能、アプリケーション、変更の最も一般的なユースケース、つまりお客様にどのように機能するかを定義します。

恐ろしい道。

テストケースでカバーする 2 番目に重要なテストパスは、名前が示すように不快感があるため省略されることがよくあります。いわば「恐ろしい道」、つまりネガティブ テストです。このパスは、コードの動作不良やエラー状態になる原因となるシナリオを対象としています。非常に脆弱なユースケースが関係者やユーザーに高いリスクをもたらす場合は、これらのシナリオのテストが特に重要です。

知っておいて使用を検討すべきパスが他にもいくつかありますが、通常はあまり使用されていません。次の表にその概要を示します。

テストパス 解説
怒ったパス これにより、エラーは想定どおりですが、想定どおりのエラーが発生します。たとえば、エラー処理が正しく機能していることを確認したい場合などです。
滞納パス このパスにより、アプリケーションで実行する必要があるセキュリティ関連のシナリオに対処できます。
分離されたパス アプリケーションでシナリオをテストするパスでは、null 値をテストするなど、機能するのに十分なデータが得られません。
忘れた道 データ損失を引き起こすなど、十分なリソースがない状態でアプリケーションの動作をテストする。
不確定パス アプリでアクションを実行したりユーザー ストーリーをフォローしたりしようとしているものの、それらのワークフローを完了していないユーザーを対象にテストします。これは、ユーザーがワークフローを中断した場合などが該当します。
貪欲な道 膨大な量の入力やデータを使用してテストしようとする。
ストレスの多いパス アプリケーションが機能しなくなるまで、必要に応じてなんらかの方法でアプリケーションに負荷をかけようとします（負荷テストと同様）。

これらの経路を分類する方法はいくつかあります。一般的なアプローチは次の 2 つです。

  • 等価パーティショニング。テストケースをグループまたはパーティションに分類し、その結果として等価クラスを作成するテスト方法。これは、あるパーティション内の 1 つのテストケースで欠陥が発見された場合、同じパーティション内の他のテストケースでも同様の欠陥が発見される可能性が高いという考えに基づいています。特定の等価クラス内のすべての入力は同一の動作を示す必要があるため、テストケースの数を減らすことができます。等価パーティショニングの詳細を確認する。
  • 分析の制限。境界値分析とも呼ばれるテスト方法です。入力値の限界や極端な点を調べて、システムの機能や制約の限界で生じる可能性のある問題やエラーを見つけます。

ベスト プラクティス: テストケースの作成

テスターが作成する従来のテストケースには、実施するテストの内容の把握と、もちろんテストの実行に役立つ具体的なデータが含まれています。一般的なテスターは、テスト作業を表にまとめています。この段階で使用できるパターンは 2 つあります。テストケースを構造化するのに役立ちますが、後でテスト自体も作成できます。

  • Arrange, act, assert パターン「arrange, act, assert」（別名「AAA」や「Triple A」）のテストパターンは、テストを 3 つのステップに整理したものです。つまり、テストの配置、テストの実行、結論の導き出すという 3 つのステップに分けます。
  • Given, when, then パターン。このパターンは AAA パターンに似ていますが、行動主導型の開発にいくつかのルーツがあります。

これらのパターンについては、テスト自体の構造については後ほど説明します。この段階でこれらのパターンについてさらに詳しく知りたい方は、Arrange-Act-Assert: A pattern for creating goodtesting と Given-When- Then という記事をご覧ください。

この記事で学んだことを踏まえ、一般的な例を次の表にまとめました。

情報 解説
前提条件 テストを作成する前に行うべきこと。
テスト対象オブジェクト 確認が必要な項目
入力データ 変数とその値。
実行するステップ テストの効果を高めるために行うすべてのこと（テストで行うすべてのアクションやインタラクション）。
期待される結果 実現すべきこと、達成すべき期待事項。
正解値 実際の動作

自動テストでは、間違いなく役立つとしても、テスターが必要とする方法でこれらのテストケースをすべて文書化する必要はありません。注意を払えば、これらのすべての情報がテストで確認できます。この従来のテストケースを自動テストに変換してみましょう。

情報 テストの自動化への変換
前提条件 テストの設定、テストのシナリオを実現するために必要な要素をすべて検討します。
テスト対象オブジェクト この「オブジェクト」は、アプリケーション、フロー、ユニット、テスト対象のコンポーネントなど、さまざまなものを指します。
入力データ パラメータ値。
実行するステップ テスト内で実行されたすべてのアクションとコマンド、実行した対象、特定のことを行ったときに何が起こるかを明らかにします。
期待される結果 アプリケーションの検証に使用するアサーション（アプリケーションでアサートするもの）。
正解値 自動テストの結果。