Tricentis Tosca Test Case Design: Top Tips

I’m commonly asked to share “tips and tricks” or best practices about Tricentis Tosca test case design. This isn’t as easy as it may seem, because there is no “one size fits all” solution to test case design. A strategy that’s well-suited to one organization might be too flexible—or too restrictive—for another.

With that in mind, I’d like to share some key considerations for creating an effective test case design with Tricentis Tosca:

Free your mind from sticking to a perfect world

First, keep in mind: If I have a business use case and design a test case for it, it will look different from the test case any other person would design. It likely will have some common points, but depending on the need, the usage (more functional, more businesslike), the experience, and the designer’s understanding, the test case will differ completely. I would even go so far as to bet that 10 people would create 10 different versions. Test case design is unique for every use case.

Guidelines are for options, not for need

It does not matter which guidelines you want to follow to design the “perfect” test case. What matters much more is that you have considered every option from these guidelines, and chosen the right one to solve your problem. Saying: “A test case needs for sure to have…” will lead to failure and inconsistency. I promise! Certainly, you will need to align your test sheets to use classes and use common sense, so everybody can read and work with your test case – that’s a fact. But aside from that, always stay open minded, and dare to try out new things and make changes, even if you go backwards more often than you progress. The worst thing that could happen is that you increase your knowledge and trust your solution even more.

If you stop moving, you are dead

It’s not just sharks that die if they stop moving – it applies to test case design too. Imagine this: there is one story within your sprint which enables a new feature. Your proven and close-to-perfectly designed test case has no chance of handling this, and doesn’t give you the chance to add it as a good fit. So, what are going to do? Go for a worse, unsatisfying solution? Change it your test case! Embrace the challenge and try your best to reach that near-perfect state before, just with the element you needed in there. If it’s not as flexible as needed, it’s not a mature enough test case.

Keep your focus

There are always guidelines within a company that tell you where your focus should be. Keep it simple, try to get a high quote of classes (not everything should be a class!), and strive to keep it maintainable and readable. Don’t lose yourself in structure and ask for a second opinion. What’s a perfect solution worth, if no one can read it or work with it? Be functional and simple, but don’t miss the business logic. Think in the big picture and not only within your use case. Most of all, don’t strive for perfection, you won’t reach it anyways.

Clear out your doubts

Be sure to understand the importance of test case design. Start with test case design early in your implementation and stick with it. Reasons to do test case design could include having functional templates, to store your test data, to display your workflow, to have business readable test cases, to have all your test cases together, to improve maintenance, and so on.

Here’s some options you could work with:

• Test cases usually have 3 main parts: precondition, workflow, post condition. You could structure your test sheets like that. Use a precondition for accounts you need in your test case, materials or other stuff like environments, browsers or users. Take stock of your workflow for all the data you use within your test case, and what you need to get it done. In the post condition, put in verifications and maybe save the things you need to clear upfront in the next test case.
• If you have more than 4 to 6 attributes, group them and make a new level within the structure. This one is impossible for some cases (bank accounts, bookings, etc.) but for those where it’s possible, just do it. Everyone who needs to read or work with it will be thankful.
• The decision between single choice and type field is easier than you may think, and change between them is a single click. Just find out what you prefer. Type fields are great for constantly changing values which are different from instance to instance.
• Use different colors for verifications and administrative attributes.
• Practice designing test cases as often as possible. Get used to the shortcuts and study the test cases that others have made. You may improve by seeing different things.
• Start with one instance, ignore the rest, and just fill out what you need. Then progress with every further instance and let it grow bigger and bigger with every variant you add. Change the structure when needed (you will, I promise).
• Align with other test sheets to ensure they have the same structure. If everyone has error messages as plain text, do the same. If everyone has the single choice error and the message as a value, do the same. If the message is only in the test case section, investigate the purpose for that decision.
• One test sheet contains one straight through and its variants, including negative test cases. A variant is a different option of the straight through within the same business workflow. A negative test case is a straight through which ends at some point with a predefined reason.
• The usage of functional switches in test cases is allowed. Maybe use the “value” attribute below to have data for the usage stored.
• Use classes where they make sense. Use it for predefined and repeating actions and values (bookings). Do not use it for changing data and if every variant is different.
• A test sheet usually should not contain 100 instances.
• A test sheet can be a Class and be reused in other test sheets.
• Putting test data management structure in a separate test sheet makes sense, but keep it stored for later changes and as a backup.

Finally, there is only ever one way to improve: by doing it. Learning requires practicing. Try out what makes sense to you – even try the stuff that doesn’t make sense – understand it, use it, throw it away. After a period of time, you will see it’s easier than you first thought. Keep on going, and let me know what you think about it and what your challenges you are facing.