Why Automated Test Design is Agile

In my career I have been asked this question a lot of times. How will your approach (to test design) help us to work in a more AGILE way?

More big and small companies are moving from Waterfall to AGILE. Why are they doing that? Simply to do things faster and adapt to a business where complexity is increasing every day because it’s now becoming the only way to keep things working on time.

We all remember when we had to deal with only one computer platform, one OS, one app, etc. But now it’s much more complicated. How many new platforms do we have? PC, Tablet, Phone, Cloud, Watch and I’m sure more are coming soon. And with all that, we also need to deal with multiple releases every month or sooner. This complexity and speed does not allow us to lose any time on tasks that are not required. Because it’s hard to have: faster time to market, deal with greater complexity, and lower costs. The solutions for these challenges are often in conflict with each other so how can we play on all aspect at the same time?

“No one should spend their lives on meaningless work. Not only is it not good business, it kills the soul.”

“SCRUM – the art of doing twice the work in half the time”, by Jeff Sutherland & J.J Sutherland

I have been reading this book and highly recommend it to you. And this quote stayed in my head. Because how long did we spend some time doing and redoing things? How long did you spend on documentation that nobody really read? Or maybe how many tests have you done that you had to redo again and again? I can hardly imagine how long I spend.

Now, let’s come back to the technology. Why test design is AGILE?

It’s simply because with test design, you will need to always reuse the work you have done before. If you use an advanced MBT approach like I do, first you will build your graphical model and reuse it for the next evolution. With this approach you will definitely work on the complexity of your system under test. No need to start again from scratch. Another point here, with advanced MBT it’s the test case generation, test script generation, and execution you will do with a simple mouse click after modeling. Everything is automated so you work here on the time to market part!

Now what about team communication?

This approach will help you to have better specs and understanding of your system. The revolution here is, at the same time as development, the test team will model the system and find issues in the requirements directly. This will prevent losing time and money by developing unusable features. To show you the cost of an issue, I will use a study done by NASA called : “Error Cost Escalation Through the Project Life Cycle”( https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100036670.pdf).

We can easily see in this table the real cost of an issue and the importance to find it before the test phase and the development phase. And the only way to do this is to create a graphical model based on the design specs.

It’s really the first thing that a user should do, experiment with test design. By doing a model it will help you to better understand your requirements but also help to improve the requirements! Seeing is understanding.

Alexis Despeyroux is a Conformiq technical field application engineering specialist.