テストケースを作成する際に従うべき 10 の重要なガイドライン
テスト管理ツールコラム
開発チームは普段大量の機能を備えたビルドをプッシュしているため、必要なすべてのテスト ケースを作成したり、リポジトリにすでにあるテスト ケースをレビューしたりする時間はありません。
それを念頭に置いた上で、アプリのリスクの高いコンポーネントの詳細なテストを作成することに時間を費やすべきでしょうか、それともシステム全体の 80% を超える健全性テストを作成するのに時間を費やすべきでしょうか?
この記事では、テストケース作成のベスト プラクティスについて説明します。テスト ケースの作成は芸術であり、アプリケーションの品質を保証するには、テストが関係者全員に明確であることがプロセス全体にとって非常に重要です。
テストにおけるテストケースの役割
テスト ケースでは、作業手順、期待される結果、テスターが検証する必要がある条件を指定します。これは、アプリケーションまたはその機能の 1 つが当初の計画どおりに動作しているかどうかを判断するために必要な基本的なドキュメントです。
製品またはその機能がリリースの準備ができているかどうかを判断するには、通常、多数のテスト ケースを作成して実行する必要があります。
テストケース、またはテスト スイートと呼ばれることもありますが、アプリケーション、ソフトウェア、またはシステムの指定された要件または暗黙的な要件から派生します。ユーザー ストーリーを実用的なテスト ケース コマンドに「変換」するこのプロセスは、ソフトウェア テスターとして開発すべき中心的なスキルです。
これにより、さまざまな質問が生じます (最も一般的な質問は次のとおりです)。
- テストケースはどの程度具体的または広範囲にすべきでしょうか?
- 最初にどのテスト ケースを作成する必要がありますか?
- 機能のどの側面をカバーする必要がありますか?
- 効率を維持するには、テストはどれくらいの長さ、または短くすべきでしょうか?
時間には代償が伴う限られたリソースがあるため、ソフトウェア テストでテスト ケースを作成する場合は、ベスト プラクティスに従って、最善の投資収益率 (ROI) をもたらすテスト ケースを賢明に書き留めてください。
テスト ケースのベスト プラクティス – 優れたテスト ケースを作成する際に従うべき基本ガイドライン
- リスクと優先順位に基づいてテスト ケースを検討するプロジェクトのタイムラインとアプリケーションのリスク要因に基づいて、どのテスト ケースを作成するか優先順位を付けます。6 週間以内にリリース予定の高リスク機能は、来週リリース予定の低リスク機能のテストよりも優先される可能性があります。主な理由は、プロジェクトの後半では、高リスク機能のテストを作成する時間がなくなる可能性があるためです。テスト ケースの公式は存在しないため、この方程式を繰り返し解く必要があります。
- 80/20 ルールを覚えておいてくださいテストの 20% でアプリケーションの 80% がカバーされます。これが健全性テストとスモーク テストの背後にある原則です。短いシナリオを書くだけでも、バグの重要な部分を明らかにすることができます。そのため、エンドツーエンドの健全性スイートから始めて、特定の機能についてさらに詳しく説明し始めるのが最善の理由です。さらに、特定の機能をカバーする場合は、さらに深く進む前に、その機能をエンドツーエンドでカバーする短いテストに取り組むことをお勧めします。
- 必要に応じて他の人がテスト ケースを完了できるようにするどのテストを作成するかを選択するときは、どのように「アウトソーシング」できるかに焦点を当ててください。たとえば、他の人には任せられないリスクの高いタスクをテストするのに忙しいときに、開発者に実行してもらうことができるテストを作成します。** 場合によっては、すべての対象者に適した 1 つのテストを作成することが不可能なため、1 つのテストの 2 つの異なるバージョンを作成することを検討することがあります。
- 「十分な」テストケーステストの作成は決して一度に完了するものではありません。多くの場合、現時点で「十分な」テスト ケースを作成する方が良いでしょう。可能であれば、将来的に必ず改訂してください。このアジャイル/反復的なリファクタリング アプローチは、開発タスクだけでなく、テスト ケースの作成にも適用されます。
- スプリントではなくマラソンを走っているかのようにテスト ケースを作成します将来のスプリント/ビルド/リリースに関連するテストを作成します。具体的にしすぎると、その関連性はプロジェクトのこの段階でのみ持続します。
- テストを作成する前にリストを作成するリスクに基づいてトピックとその優先順位のリストを作成します。これにより、必要なものやテストしたいものに集中し続けることができます。リストが最終的なものではない場合でも、後でテストを分割したりマージしたりできます。
- ビジネス シナリオと機能に基づいてテスト ケースを分類するこれにより、システムをさまざまな角度から見ることができます。このプロセスの背後にあるロジックは、どのようなテストをいつ作成するかを知ることです。区別することは、テスト リポジトリ内でテストを整理するのにも役立ちます。そのため、あなたとあなたのチームは、将来のテスト計画のニーズに基づいて実行できるテストを選択できます。
- 長すぎず短すぎずテスト スーツは、実行に 45 ～ 90 分かかり、同時にシステムの重要な領域を「一度に」カバーできるように定義する必要があります。
- テストを試行する最初に作成したテストは、完成させるまでに 1 回か 2 回実行される可能性があります。したがって、他の人に送り出す前、または顧客にリリースする前に、必ず試乗テストを受けてください。
- テストを定期的に実行して関連性を維持するアプリケーションの変更、環境の変更、その他多くの理由などの制約に基づいて、テスト ケースに継続的に小さな変更を加える必要があります。小さな変更を加えるのは迅速かつ簡単であり、完全なオーバーホールを行って新しいテストを最初から作成するよりも優れています。
最終的な考え
では、ソフトウェアテストにおける良いテストケースとは何でしょうか? もうおわかりかと思いますが、この質問に対する単純な答えはありません。ただし、上記のポイントで述べたように、テストの関連性を維持し、重大なリスクが未発見のままにならないようにするために講じることができる対策があります。
PractiTest などのテスト管理ツールも、テスト ケースの管理や、テスト ケースの状態を常に追跡するのに非常に役立ちます。このようなツールを使用すると、さまざまなパラメータごとに編成されたテスト ケースの構造化されたリポジトリを維持できるため、テストの状態を常に追跡してテストが最新であることを確認できます。
PractiTest(プラクティテスト)に関する
お問い合わせ
PractiTest(プラクティテスト)のトライアルアカウントお申し込みや、製品デモの依頼、
機能についての問い合わせなどお気軽にお問い合わせください。
※この記事は以下の記事を意訳した記事になります。
引用元：「What is a Test Plan? The Complete Guide for Writing a Software Test Plan」
