Of course, you can, can’t you?
It all depends on what you mean by a regression test suite. With a moment’s reflection, you will find there is a significant gap between what the business wants from such a test and what a coded test automation tool can actually deliver.
Let’s have a look at the gap.
The business needs to mitigate risk. When a key application is updated, the business needs to know that the changes have been properly tested, but that is not the purpose of a regression test. The regression test exists to ensure that aside from the changes, everything else still works as before. It is the corporate insurance policy.
So, to determine if your existing tool can achieve this, we need to look in a little more detail. Let’s consider a simple scenario:
A Customer Number, if keyed on the first screen, and after clicking ‘Next’ on the following three screens, the Credit Limit is lifted from the final screen and compared to the expected value.
In a coded automation tool, this is easy-peasy lemon squeezy.
But hold on a moment. What if screens 2, 3, and 4 were empty aside from the ‘Next’ button? I think we can agree that it would be a problem. But it wouldn’t be flagged by a coded regression tool.
What is actually required is that every element on every screen is checked against a baseline, and every unexpected difference is reported.
Now, try asking your automation engineers to code that.
Hang on; I see one of you has put their hand up. You want to say that while your current coded regression test doesn’t check every element on every screen, with some additional time and a few more automation engineers, it could be easily achieved.
I fear you may be missing the point. Today’s business needs quality it can rely on and it needs it now. It expects every area of the business to be doing more with less – and if not less, then certainly no more.
So if you want to do time-relevant regression testing but are stuck with coded automation tools, you’ll find they’re incompatible.
Time for a new approach…
