Best practices | TestCases | Verifications

As we mention in "Best practices | TestCases | Content", every TestCase must have a defined outcome. That way, your TestCases are definitive proof that your application meets its quality and success criteria.

If you only check your TestStep results, you'll only know whether Tosca successfully performed all steps of your TestCases. However, to determine whether the TestCase actually has the expected outcome, you need to add verifications.

TestStep results vs. verifications

Let's say you're testing an online shopping process: adding an item to the cart. Tosca searches for the item, selects it from the search results, and adds it to the cart. So far, so good. Now think about the expected outcome: there should be one item in the cart, and the cart should show the correct total price.

Tosca passed all TestSteps, but this only tells you that the process of adding something to the cart works. You still don't know whether your application successfully completes the process and displays everything in the cart. That's where your verifications come in.

To add verifications, use ActionMode Verify.

This TestCase verifies whether the number of items and the total price are as expected

What not to do

It may seem faster and more convenient in the moment, but don't put all your verifications into one big TestStep at the end of your TestCase. You'll have a much harder time analyzing results: if the verification at the end fails, you only know something's not working but can't pinpoint where the problem first appeared.

Let's go back to our webshop example:

  1. Tosca searches for an item, picks it from the search results, and adds it to the cart. All steps pass.

  2. Tosca repeats the process for another item. All steps pass.

  3. Tosca repeats the process for another item. All steps pass.

  4. Tosca repeats the process for another item. All steps pass.

  5. Tosca performs a series of checks on the shopping cart. That's your only verification and, unfortunately, the total price isn't right.

Now you're stuck trying to figure out where, when, and why the application broke. If you'd verified along the way, you'd be able to narrow this down significantly.

A better approach

Let's compare this to a test flow with verifications for every step: 

  1. Tosca adds the first item to the cart, all steps pass. The verification also passes: number of items in the cart and total price are as expected.

  2. Tosca adds the second item to the cart. All steps pass, and so does the verification.

  3. Tosca adds the third item to the cart. All steps pass, and so does the verification.

  4. Tosca adds the fourth item to the cart. All steps pass. However, according to the verification, the number of items in the cart is correct, but the total price is not.

  5. Tosca performs a series of checks on the shopping cart. According to your verification, the total price is wrong.

In this case, you save valuable time by starting your investigation with step 4 instead of step 1.

What's next

If you haven't yet, check out our other best practices articles.