Test Automation and the Greedy Expectations….!!!

I have been dating Test automation for the past decade and am never bored of it all the time. She has been a fascinating partner, making my life merry when I take care and making it a living hell, when I do not.

Automation is always is a double edged sword and I use this phrase many times today (read decade), because my excitement in automation has led to advocating responsible automation. It’s another question on whether I am able to sell it or not always.

A good part of my energy and effort has gone by in proving Test automation is the right thing for its most hardest critic and Test Automation is not the golden goose for its easiest subscriber.

Automation should not be seen as the magic wand that solves all of the problems, especially Testing. It can address concerns over schedule and cost in the long run, but may fall flat on providing good quality systems if it is being harassed. Automation builds a degree of predictability, but always misses to find out of the box defects.

Test Automation in theory is another piece of code that is built on an existing code called application/system. It would have defects, it would have changes , it would work , it wouldn’t work , it may find defects and it may not find.

Just like the way application code changes very frequently , “AUTOMATION CODE ALSO WOULD CHANGE”. There is no running away from this phenomena.  A lot of times, I have PMs and Architects pointing at failures of Automation. I tell them, it is bound to fail. It should fail. What is the need for it if everything passes ?

I find it hard to understand what they need from Test automation code , is it “Magic”. We plain engineers, architects building line of code dependent on so many facets of software development factors.

If there could be maintenance releases for application code, I ask why couldn’t all accept that automation code base also needs maintenance.

Does anyone believe that Test Automation is more complex than application development, whoa didn’t I raise some eyebrows here.

·         Application code is derived from requirements. Automation code is based on application behavior and requirements.

·         Application code is bound to make the requirements a reality. Automation code should validate the requirements against the built system

·         Application code is usually the first line of representation of requirements, Automation code is built based on multiple representation of requirements (environment, technology, tools, test scenarios etc)

A growing and a relevant trend is to tie automation to the parent code, build components , reduce dependency on UI layers. Absolutely the way to go. Automate as much as possible at the interface layer and as much as needed at the UI layer.

Testing as a function cannot change to build everything at interface layer and abandon the UI layer once for all. The job of test automation is also sign off the system the way end user would do, do we expect the end user to test APIs only ?

The hardest critic of test automation just needs to know the value of test automation, where the hypnotized believer of Test automation wishes for sun.

Today, that’s the unfortunate direction we as an industry are heading at . Everyone wants to automate and everything needs to be automated.

I am fascinated the ease at which “reset button is hit”  , when understanding the expectations from Test automation is desired. We do not learn from mistakes and we always re-invent the wheel. 

Am rest assured, this is not a concern only with Test automation, rather across the board where specializations are involved.

But it is a mystery , on how right things could be overlooked, not because they are not aware but many do not want to be aware.