新しいテストケースを作成する

おそらく、QAチームはアプリケーションの品質と成功基準を考案することに多くの時間を費やしたのではないでしょうか。アプリケーションが実質的にこれらの基準を満たしていることを、テストケースが確実に証明していることを確認してください。

これを行う最良の方法は、テストケースに検証を追加し、アプリケーションが期待される結果を示しているかどうかを評価することです。

テストステップの結果のみを確認しても、Tosca Cloudがテストケースのすべてのステップを正常に実行したかどうかしかわかりません。しかし、テストケースが実際に期待される結果になっているかどうかを判断するには、検証を追加する必要があります。

例えば、商品をカートに追加するというオンラインショッピングのプロセスをテストしているとします。Tosca Cloudはその商品を検索し、検索結果からそれを選択してカートに追加します。ここまでは順調です。ここで、期待される結果について考えてみましょう：カートには1つの商品が入っていて、カートには正しい合計金額が表示されているはずです。

Tosca Cloudはすべてのテストステップを通過しましたが、これはカートに何かを追加するプロセスが機能していることしか表しているにすぎません。アプリケーションがこのプロセスを正常に完了し、カート内の中身がすべて表示されているかについては、まだわかっていません。お客様の検証が役に立つのはまさにこの段階です。

自己完結型のテストケースは、他のテストケースを先に実行する必要がないテストケースです。完全独立型のテストケースでは、より信頼性の高い結果が得られます。いつでも任意のテストケースを実行でき、偽陽性や他のテストの中断、重要な関連フローの取りこぼしを心配する必要はありません。

さらに、プレイリストに自己完結型のテストケースのみが含まれている場合は、テストを実行する最速の方法であるパラレルモードを使用できます。

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

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

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

2. テストケースAは、その後、特定のワークフローをテストするためにアプリケーション内を移動します。

3. テストケースAは、メインメニューに戻ります。それが終了点です。

4. テストケースBの開始点もメインメニューです。テストケースBは、テストケースAが終了した場所から再開できます。

ステップ3がない場合、テストケースAが終了するポイントからテストケースBが開始するポイントまでの移行ステップをテストケースBに統合しなければなりません。つまり、テストケースBを独立して実行することはできないのです。

あるいは、これらのステップで「フィラー」テストケースを作成し、そのフィラーテストケースをテストケースAとBの間で実行しなければなりません。しかし、フィラーは良いアイデアではありません。

通常、フィラーテストケースは、自己完結型テストケースについて前のセクションで説明したようなシナリオが原因で発生します。それらは、準備や移行のテストステップが一つか二つしかないテストケースです。これらの小規模なテストケースが多数あると、所有しているテストケース、これから必要になるテストケース、そして何がまとめられているのかを把握しづらくなります。さらに、余分なメンテナンス作業も発生します。

この状況を避けて、実際の対象物をテストするテストケースに時間をかけてください。