Five rookie mistakes around Automated Test Design. You probably read this because you are interested in Automated Test Design or simply because you are working with the technology. But before I go through these five rookie mistakes, let me first recommend that you always check the technology vendor. “Testing” in general has evolved a lot during the past couple of years. From a model you can, of course, generate a full test suite but you can now also generate fully automatically executable test scripts directly. I’m not here to talk about that but it’s really a recommendation: Check your vendor technology 🙂
Let’s start with our five rookie mistakes.

1. START FROM NOTHING

I know a new technology is always fun and some of you just want to jump in this new way of working. After being frustrated from writing tons of word documents for manual testing you want to spend time on modeling from scratch.

But always ask yourself:

What can I reuse to be on track faster?

Because yes, we can reuse test and requirements assets!

For example: Visio diagrams, recordings, existing manual test cases, test plans, WSDL files, BPMN diagrams, etc.

So, don’t spend your time on rework of something you have already done. Instead import it!

2. MODELING INTERFACES IN TOO MUCH DETAIL

Modeling in general is fascinating. In a simple language, you can express all the interfaces your application provides for testing. But think again: Do you really want to model every conceivable detail? So my second advice to you is:

Think AGILE

Only target the most important interfaces of your application: what brings the most value? Tell yourself that if you have time you will improve your diagram and go into more detail later. Do not target everything. Don’t forget that 20% of your work will bring 80% of the value. And the 80% is still much better than the old way of working!

3. OVERUSE OF COMBINATORIAL DATA

This point here is something that I often see. You have plenty of possible data that you want to test. Do you really want to test your 500 logins and passwords in functional testing? Are you really interested in executing tests that test all combinations of your 4 form fields that which each can have one of 10 possible values? Or in other words:

Do you really want to execute 10,000 possible tests?

Yes, this may sound funny when you read this but lots of new users do that. So always try to take some value that makes sense not to test all the values you can test. Always question yourself around that. What do I need to include to test the functionality of the SUT – Probably not all data combinations.

4. MODELING ONLY HAPPY PATH[S]

Most of users when they start modeling will model only happy path. This is a good thing but why not model alternative and invalid behavior?

By modeling alternatives and invalid behavior, it’s where the tool will generate test cases that you can’t think of! So, question yourself [what would happen if ….]? And the tool will generate for you the corresponding test case.

5. OVERUSING CUSTOM MODELING EXTENSIONS

Let me explain what a custom model extension is: It’s a way to extend your modeling language, e.g., with a custom action, when you are stuck in a situation where no predefined action provided by your modeling language “feels” suitable.

Here the important word is “feels” in that sentence. When you decide to create a custom modeling extension you really need to be 100% sure this cannot be achieved in another way. Introducing such an extension as part of a library that is suitable to be reused not only for one purpose but across different diagrams or even projects resolves this issue much more elegantly as it brings readability, consistency, and allows a direct transition from generated tests to automatic execution.

I hope all these 5 points will free your mind and bring you some value during your modeling. In conclusion, modeling changes lots of things in the way we work. It’s always good to question and talk about the way you work and how to improve modeling inside you team. All that will put you on the road to become a JEDI TEST DESIGN MASTER!

May the Modeling Force be with you and i hope you will never do the five rookie mistakes again!

Thank you for reading! Please comment!

Alexis Despeyroux – Certified ISTQB Test Manager.

Contact us ! 

Comments are closed