Browser-based testing in NeoLoad with RealBrowser
Available as of NeoLoad 9, RealBrowser is included in all editions of NeoLoad and provides browser-based testing capabilities alongside already robust protocol-based testing.
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:
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.
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.
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.
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.
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:
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.