Do Automation testers test?

I won’t be too revealing if I say that the IT industry is striving for automation. Automated development, automated documentation, automated deployment and ongoing work on implementing AI… basically everywhere. And testing. Good old testing. Something most obvious in that matter. Who would like to check 1000 manual test cases after every small fix? Who would like to retest the same thing on and on? Which company would wait a few days for the test results of some crucial hotfix? There is no other answer than “Test automation is the way to go”. But do engineers responsible for test automation are testers anymore?

As many other testers I also started from being a “clicker” of front end applications. Above all I had to know the product, know which feature to focus on, understand the process and the changes that have been implemented into application. Then, verifying if the application functions works as expected based on my expertise, experience, and intuition. Usually sooner than later such tester can become automation one. So take a closer look at what such person’s responsibilities are.

Transitioning from a manual tester to a new role

You will probably start with investigating regression (or any other test pack with highest priority). Rewriting test scenarios into test framework code. Test scenarios which were usually covered by manual testers before.

Maybe you will have more technical background and will be responsible for writing test framework functionalities — as a result, be able to cover more regression test scenarios… that were usually covered by manual testers before.

Maybe you will be thrown into some Ops responsibilities and will focus more on the automation testing process. Building test pipelines, that will provide regression results on demand… that were usually covered by manual testers before.

Or maybe you will take on an automation lead role. Conduct a team of engineers that are automating work that is usually done by manual testers or in other words — keeping an eye on test framework product implementation. Last two words are key here.

Are automation testers still testers?

Isn’t that we (automation testers) are mainly developers of a product called testing framework? We don’t directly test anything. We provide a tool that will do the testing instead of a human being. We support testing process, but honestly we do not test.

Even the recruitment process doesn’t focus on testing skills. We make sure that the candidate knows about ISTQB and has a testing mindset, but only to a minimal extent, since we no longer require it. We want them to understand data flows, or know how to locate Selenium locators, or know how to work with version control and above all we want candidates to understand the code. Why do we recruit that way? Because we need those skills and abilities on a daily basis. No one requires testing skills from us, so we don’t look for it in others. We don’t have to deeply understand implemented features, we don’t have to think about border cases, do exploratory testing, prepare detailed reports that will be reviewed by test managers or even ask ourselves “Does this work?”.

Is this a bad thing? No! As long as we are separating tester from a test engineer role.

Manual testers vs test automation engineers

I was a part of a project where there was one test team — consisting solely of automation engineers. Our goal was to automate everything. Whole process. From the beginning to end. End to end automated test cases, dockers, automated test environments, test pipelines, automated reports, CI/CD… but no one felt responsible for the quality of the product. Even defining what the product is for our test engineers was not clear. Some of us were brutally honest saying loudly that they don’t even know how to use our application. Modifying that process was mission impossible. Test engineers were offended at the mere thought of manual testing. Exploratory testing meeting almost ended in mass terminations. Everything was automated, but the quality was poor. It wasn’t working.

On the other side I was working on a project where almost all testers were manual ones. Theoretically there was a testing framework, developed for the last 5 years by random people implementing whatever will come up to their minds, with no management, goal and blueprint. As a result no one was using it and everything had to be tested manually. At least the quality of the tested product was really high, but automation was only theoretically “put on paper”.

Conclusion

So how to deal with all that? Do not treat test automation engineers as testers! Because they are not the same anymore. Those are two separate roles. At the end of the day, Projects should have people responsible for testing that will provide information about the current quality of tested product. Additionally, test automation specialists should be involved to support the testing process, reduce the number of resources needed, automate repetitive tasks, and reduce the time needed to make the product ready for release. IT needs both of them. Good test specialist with “error radar” might be more valuable to the project than thousands of automated test cases. On the other hand — a simple test automation tool can save thousands of work hours, e.g. when generating test data.

Unfortunately having such wide range of responsibilities for one person would be a waste of… automation skills. Why? Because of market demands. Today we want to automate everything, make things faster, quicker, more AI. So maybe the problem is that IT stopped valuing testing as such?

After that question, there is nothing left for me to do but to… not answer it. Hoping that you will try to answer it yourself.