Throughout my career, I have been asked this question many times. How will your approach (to test design) help us work more AGILE?
More and more companies, small and large, are moving from Waterfall to AGILE. Why are they doing this? It is simply about doing things faster and adapting to a business that is increasing in complexity every day, because it has become the only way to get things done on time.

We all remember the days when we had to settle for one computing platform, one operating system, one application, etc. But today it is much more complicated. How many new platforms do we have? PC, tablet, phone, cloud, watch and I am sure more will come soon. And with all this, we also have to deal with multiple releases every month or sooner. This complexity and speed does not allow us to waste time on tasks that are not necessary. Because it is difficult to have: faster time to market, greater complexity and lower costs. The solutions to these challenges are often in conflict with each other. How can we play on all sides at the same time?

« No one should spend their life in meaningless work. Not only is it bad business, it kills the soul. »
« SCRUM – The Art of Doing Twice the Work in Half the Time », by Jeff Sutherland & JJ Sutherland

I read this book and I highly recommend it. And that quote stuck with me. Because how much time have we spent doing things over and over again? How much time have you spent writing documents that no one has really read? Or how many tests have you done that you have to do over and over again? I can’t imagine how much time I spend on that.

Now back to technology. Why is test design AGILE?
It is simply because with test design, you will always have to reuse the work you have done before. If you use an advanced MBT approach like I do, you will first build your graphical model and reuse it for the next evolution. With this approach, you will certainly work on the complexity of your system under test. There is no need to start from scratch. Another point, with advanced MBT, test case generation, test script generation and execution are done with a single mouse click after modeling. Everything is automated, so you are working on the « time to market » part here!

What about communication within the team?
This approach will allow you to have better specifications and a better understanding of your system. The revolution here is that, at the same time as development, the testing team will model the system and find problems directly in the requirements. This will avoid wasting time and money developing unusable features. It will force you to cooperate better.

To show you the cost of a problem in a traditional approach, I will use a study done by NASA called « Error Cost Escalation Through the Project Life Cycle ».

Table 4: Software cost factors in a traditional agreement

What is the cost to your business if you stick to tradition? We can easily see in this chart the real cost of a problem and the importance of finding it before the testing phase and the development phase. The only way to achieve this is to create a graphical model based on the design specifications.

This is really the first thing a user should do, experiment with test design. Making a model will help you better understand your needs, but also improve them! Seeing is understanding.

Thanks for reading! Please feel free to share your comments with us!

Read more at: https://www.conformiq.com/category/blogs/

If you have a specific topic, please let me know!