べストプラクティス | TestCases | コンテンツ

テストケースは、Toscaがテスト対象のアプリケーションで実行する一連のステップです。テストケースの内容に関する基本的なルールについて説明します。

結果を定義したテストケースを作成してください。

おそらく、QAチームは、アプリケーションの品質基準や成功基準の策定に多くの時間を費やしてきたことでしょう。アプリケーションがそれらの基準を満たしている、という明確な根拠をテストケースで示すことが必要です。

これを示す最善の方法は、検証を組み込んだテストケースを設計することです。アプリケーションが予想通りの結果を示しているか否か、を簡単に評価できます。詳しくは、 "ベストプラクティス | TestCases | 検証" をご覧ください。

自己完結型のテストケースを作成する

自己完結型テストケースとは、他のテストケースを最初に実行する必要のないテストケースのことです。完全に独立したテストケースにより、より迅速にテストを実行し、より信頼性の高い結果を得ることができます。誤検出や他のテストの中断、重要な接続フローを忘れることを心配することなく、テストケースをいつでも実行できます。

各テストケースは、定義された始点から終点まで実行する必要があります。自己完結型のテストケースの場合、テストケース後のアプリケーションの終点が始点と同じであることを確認してください。

標準化された同一の始点と終点を使用すると、移行ステップや接続フローを気にすることなく、テストケースを拡張シーケンスに組み合わせることができます。この例を見てみましょう。

1. TestCase1の開始点は、アプリケーションのメインメニューです。

2. TestCase1は、特定のワークフローのテストを実行するためにアプリケーションをナビゲートします。

3. TestCase1は、メインメニューに戻ります。つまり、終了点に戻ります。

4. TestCase2の開始点もメインメニューです。TestCase1が中断したところから再開できます。

ステップ3がない場合、TestCase1の終了点とTestCase2の開始点の間の遷移ステップをTestCase2 に統合する必要があります。つまり、TestCase2を単独で実行することはできません。

または、これらの手順で「フィラー」テストケースを作成し、このフィラーテストケースをTestCase1とTestCase2の間で実行する必要があります。しかし、フィラーを使用するのは良い考えではありません。

「フィラー」テストケースは作成しないでください。

通常、フィラーテストケースは、前のセクションで自己完結型のテストケースについて説明したようなシナリオが原因で発生します。これらは、準備用または移行用のテストステップが1つまたは2つだけ含まれたテストケースです。このような小さなテストケースが大量にあると、何があって、何がまだ必要で、何が一緒になっているのかを追跡するのが難しくなります。さらに、余分なメンテナンス作業も発生します。

このような状況を避けて、実際に何かをテストするテストケースにのみ時間を費やすようにしてください。

有用なテストケースを作成してください

お客様の目標は価値のある何かをテストする、定義された結果を伴う自己完結型のテストケースです。それ以外のものは、投資した時間に対して価値が低すぎます。

有用なテストケースには完全なシーケンスが含まれます。

• 定義された始点から定義された終点までの現実的なユーザーワークフローを表すすべてのアクション。テストケースが自己完結するように、始点と終点は同じである必要があります。

  例：アプリケーションを開く、サインインする、ユーザーインターフェースを操作する、データを入力する、サインアウトする、アプリケーションを閉じるなどです。

• テスト対象アプリケーションの予想される反応。これにより、途中で定義された結果を検証することができます。

  例えば、アプリケーションは、すべての必須項目が入力された後で初めて次へボタンを有効にしますか？与えられたデータに対して正しい結果を計算しますか？

次の記事

まだお読みになられていなければ、他のベストプラクティス記事もご覧ください。