So you finally installed your Tricentis Tosca Commander and you are ready to automate your test cases? Try to avoid the following five traps Tosca beginners often fall into. This will keep your maintenance costs low in the long term.
So let’s start right away!
1. Creating test cases without a structure
While you can quickly just start scanning modules and then drag and dropping them into your new test case, try to keep a structure that makes your test case readable. Chances are you will not be the only person maintaining your test case.
Best practice is to define at least three folders within the test case: Preconditions, Process and Postconditions.
Preconditions should contain any preparatory test steps for the testcase, such as loading test data or initializing buffers. The Process folder should contain only the actual workflow to be tested. And Postcondition may contain test steps that are needed to clean up after the workflow has been finished or to update the status of the test data.
2. Creating big modules
The module in Tosca is the technical representation of a collection of controls from a screen. While scanning the system under test (SUT) you will add controls in form of attributes to the module. However a website or form can have plenty of controls. If you add all of them to the module you may have difficulties finding the right control later on.
Try to find a logical separation of the existing controls into sections of the screen. For example you may have a top menu row which you can keep separately in one module.
Most of the time you may reuse modules with menu items for several screens, keeping them in one central module gives you better maintainability.
3. Not treating your test steps maintainable
Creating test steps is easily done by dragging & dropping modules into the test case. You then fill up the test step values and you’re done, right? Not quite, it helps a lot if you also rename the created test steps using a descriptive name such as “Click on button xy”. This will help a lot to keep the test case readable and in long term more maintainable.
Extra tip: Although you can assign multiple actions in one test step, it can help to create separate test steps per action. The test case stays more readable overall and having per test step actions keeps it more flexible for future workflow changes too.
4. Creating test cases without a verification
So you finished the whole workflow of the test case and everything is working fine. All seems fine, since you just wanted the workflow to run correctly. Therefore you don’t need any further verification, right?
Well, no, although your workflow may run correctly, it is normally aimed at a certain goal. Say you have a web shop and want to test the checkout workflow. While the workflow of selecting and adding things to the shopping basket may be covered and working, how can you be sure that the actual goal, adding things to the shopping basket, did work correctly? You will have to do a verification of what is eventually inside the basket.
All test cases should aim at a goal and this goal should be verified. Therefore implement verification test steps into your test case.
5. Over-verifying things in a test case
This is the opposite of the previous mistake. Normally you want to verify a lot of things within your application. Let’s take our web shop checkout workflow again. You want to verify that all selected positions are in the shopping basket. Furthermore the sum of the positions should be correct and certain discounts need to be verified and correctly calculated in the shopping basket.
While it may be convenient and time–saving to verify everything in one test case, you will be having a hard time to interpret the results after a regression run. A failed verification would then just give you the information that something is not working. But since your test case covers a lot of verification points you cannot pinpoint the problem. For example: What does it mean if some verifications fail and some pass? Can you still trust the passed verifications? What does that tell you about test coverage of your application?
Creating a test case which focuses on a specific verification will tell you directly what exactly has failed without having to put much effort in analysing the test run. This is something you can manage with test case design in Tosca.
However this is just a rule of thumb. Creating more test cases impacts your overall test execution speed, which may also be of great concern. As usual you may need to find a middle ground.
Conclusion
In this article we covered the importance of structure and naming in your test case, looked at module creation and what belongs into a test case.e
The 5 mistakes Tosca beginners do that are described here can be easily avoided and will let you create test cases that are much easier to maintain.
Please leave a comment if you agree or disagree. Perhaps you have some tips of your own?
Maybe you need more manpower to create your regression test set? Then feel free to contact us or directly me. Or you need more training? Then check out our Academy offering.
