I remember those first tentative moments with Tosca Testsuite. I was excited but a bit nervous. It was my first day at Tricentis and a mysterious document was placed in my hands: a tutorial. I read through it, did the exercises, and was amazed at how easy it was. Looking back on those days now, it makes me wish I’d had the Udemy tutorial to work with – that would’ve made it even easier.
Back then I was a newbie coming from another industry and I wish I’d known then what I know now. So here are two things I learned the hard way.
Make your object names clear and descriptive
Naming objects is like commenting code. If you don’t do it now, you’ll regret it later. So if you have a test case called test case 12, stop what you’re doing and change its name immediately! This is true for all objects: test cases, test steps, controls, etc.
It’s also best practice to name test cases after their related actions, and to give controls names that show their actions or their purpose (price list, progress bar, etc.):
The Risk Coverage Optimizer forms the backbone of your testing
Never, ever start your testing project without first defining requirements and designing your test cases. Requirements tell you the coverage and the execution state of each test case. Your execution list only tells you the execution state. Careful here! The information you get from execution lists doesn’t have any useful point of reference. But with consistent requirement management, you’ll know the state of your test at any time.
Test case design is a blueprint for your test. I have learned that the more complex the test gets, the more sense it makes to use test case design. It is easier to add parameters later in the process and you can make changes fast and without a lot of effort. With all the unpredictability of agile methodologies, this is a real life saver.
Any questions for your future self?
Now it’s your turn! What would you have wanted to ask your future self? What do you wish you had known as a newbie tester?
Stay connected– subscribe