When I was going through the current job offers available on LinkedIn or other sites it struck me down, that test automation is the key skill that the tester should have. Yes I have that skill personally, but things went a bit wrong in the industry and it seems like the automation is a solution for all quality issues along the development process.
Keep few testers, replace the rest of them with automation
On one side it is being shown that there is a belief of a bullet proof automation frameworks that will make most of the testers dispensable. All we need inside a project is just enough amount of test cases that otherwise would be executed by “manual” testers. This is probably taken from perception that all the testers do is creation of test cases and then blind execution of those through the user interface. This means that the role of a tester is flattened to functional testing, where there is a lot of other areas to cover.
Do not resist, give organisation what it wants
And here I see the honeypot. Yes – test engineers can have a lot of fun while building the test automation project. Yes, they will improve their coding skills (or at least overall automation skills if no-code approach will be chosen), yet this could not be called testing at all. It’s basically automated checking which is a decent way to go for regression testing. You cannot compare this solution with the tester that is walking through the app and his ability to adapt to the situation during the session. It is actually taking tester further from the focus on testing into the automation. By that being said I want to differentiate the act of development of automated tests and testing.
When you develop the automation code you wear the developer hat for the time being
You analyze how to combine test data with test implementation, you look for the assurance of tests isolation and also the way how to put the checks into the pipeline. Where is testing? Do you uncover anything about the product that you already did not know? From my experience regarding bugs being found by test automation suites, most of the bugs are spotted DURING the development of automated tests, not thereafter. Thus going with very high coverage of automation does not give the expected value. Instead how about combining the automation hype with competent testers that will not only “fill the automation gaps”, but also look for the bugs where the test automation will never be able to find them? What about going few levels deeper with testing, than the test automation would go?
Find a compromise
To wrap up the automation hype matter. Since we all need to make ourselves a living we got to follow the trends and perform some activities that might not be a pure value. We should just not go crazy with the fancy automation and perhaps veto the 100% coverage goal.
