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.
