ベストプラクティス | TestCases | 検証

で述べたように、すべてのTestCaseにおいて結果を定義することが必要です。そうすることでTestCaseは、アプリケーションが品質と成功基準を満たしているという明確な根拠となります。

テストステップの結果だけを確認する場合は、ToscaがTestCaseのすべてのステップを正常に実行したか否かのみしか確認できません。しかし、テストケースで実際に期待通りの結果が得られるかどうかを判断するには、検証の機能を加える必要があります。

テストステップの結果と検証の比較

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

Toscaはすべてのテストステップに合格しましたが、これはカートに何かを追加するプロセスが機能することを伝えているだけです。アプリケーションが正常に処理を完了し、カート内のすべての内容が表示されたかどうかはまだわかりません。そこで検証の出番となります。

検証を追加するには、 ActionMode Verify を使用します。

このテストケースは、商品の数と合計金額が予想通りであるかどうかを検証します。

ここで、やってはいけないことがあります

その場ではその方が早くて便利だと思うかもしれませんが、すべての検証をテストケースの最後にある大きなテストステップにまとめてしまわないようにしてください。これにより、結果の分析がはるかに難しくなってしまいます:最後に検証が失敗した場合、何かがうまくいっていないことがわかるだけで、問題がどこで最初に発生したのかを特定することができません。

ここで、ウェブショップの例に戻りましょう。

  1. Toscaは、商品を検索し、該当する商品を検索結果から選択し、カートに追加します。すべてのステップで合格です。

  2. Toscaは、別の商品に対して同じ操作を繰り返します。すべてのステップで合格です。

  3. Toscaは、別の商品に対して同じ操作を繰り返します。すべてのステップで合格です。

  4. Toscaは、別の商品に対して同じ操作を繰り返します。すべてのステップで合格です。

  5. Toscaは、ショッピングカートで一連の確認を実行します。それが唯一行われた検証であり、残念ながら、合計金額が正しくありませんでした。

この状態では、アプリケーションに不具合が起きた地点、時期、理由を突き止めるのに苦労することになります。途中で検証していれば、範囲を大幅に絞り込むことができたはずです。

より良いアプローチについて

ここで、ステップごとに検証を行うテストフローとの違いを比べてみます。

  1. Toscaは、最初の商品をカートに入れます。すべてのステップで合格です。検証も合格です。カート内の商品数と合計金額は予定どおりです。

  2. Toscaは、2つ目の商品をカートに入れます。検証を含めて、すべてのステップで合格です。

  3. Toscaは、3つ目の商品をカートに入れます。検証を含めて、すべてのステップで合格です。

  4. Toscaは、4つ目の商品をカートに入れます。全てのステップで合格です。この時点での検証では、カート内の商品数は正しいにもかかわらず合計金額が間違っています。

  5. Toscaは、ショッピングカートで一連の確認を実行します。検証によると、合計金額が間違っています。

この場合、ステップ1ではなく、ステップ4から調査を開始することで、貴重な時間を節約することができます。

次の記事

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