The Question

“So you are on QA. Are you an automation tester or just a tester?”

It always irritates me whenever people ask me (or another people) this kind of question. The thing that worries me is that this kind of mindset seems to start trending in the QA industry. I am talking about over glorifying the role of automated test engineer.

*To this day I still do not understand why is it so hard for some people to say automated test engineer instead of automation tester. What is automation tester anyway? Are you testing an automation system or what?

In this post I will explain a bit about my journey on QA and why we should not belittle the role of testers nor overglorify the role of automated test engineers.

The Personal Experience

I have been working as QA Engineer for about 6 years. For that short 6 years, I have been given the chance to work for various companies and interact with QA from a lot of companies as well.

On my short career on QA I have done two roles as QA Engineer:

  • Solely handling automated test
  • Testing features and handling automated test

During my time solely obligated to handle automated test, I feel that it is not a good fit for me since my product knowledge is limited. All the test cases are written by testers. I only need to automate these cases. It does not help that at those times the testers do not need to verify assertions I made on my automated tests. Generally it makes me feel that my impact to the development process is far from ideal.

In the other hand, I consider myself to bring more value for the development process when I am automating tests and also testing features. I learn a lot about testing techniques, communicating issues, tackling obstacles on development, empathising with developers, etc.

It started to make a lot of sense to me of why we need to automate good test cases. Yes, good test cases. I personally do not see any point on creating thousands of automated test that will not detect any defect as early as possible.

But do you have the time to do both? Ain’t it exhausting?

Well I would say, it is exhausting. But it is rewarding at the same time. It made me realize that there are so much to testing rather than just test automation.

I feel so lucky that I was faced early with the harsh reality: I suck at testing. A lot of the features that I tested turns out to have a lot of faulty on production. It made me thinking, “If my test cases are these bad. What is the point of automating them?”. This epiphany forces me to read, learn, and ask a lot of questions on how to test better.

I personally prefer doing a hybrid of both testing features and handling automated test. It gives me the opportunity to observe and be the best of both worlds.

The Trend

All of these are from my personal experience. Of course there are a lot of different cases for every company and individual. However it irritates me the most when I was faced with situations where the so called leaders in QA department think less of testers compared to automated test engineer.

There were instances where I saw some leaders lured testers to learn about automated test by convincing them that their salary will be better if they became automated test engineers. I think this is kind of the worst case scenario of a trend of over glorifying automated test engineer. I believe this kind of view from people who are considered to be senior in QA then influence people in the industry to overglorify testers who can write automated test.

The Unpopular Opinion

Automated test is not a magic pill & people who can automate is not a doctor that will immediately cure your problems.

Automated test is a tool that will complement your existing test activities. Testers who are and are not doing automated test should be treated equally. They possess different skill sets and can transfer their knowledge from one to another, forming a great testing team.

I would argue that writing automated test is not on the same level of difficulty of writing production features. Do not get me wrong, automated test project should be treated with the same care. But it is only logical that hiring developers for the task is simply more efficient. Most developers can kickstart automated test in a breeze.

So what makes a QA that can write automated test any special? I believe the testing skills and techniques will be the main difference that separate them. How do you acquire testing skills and techniques? By testing features don’t you think? 😉

Or if your testing team has separated testers who exclusively write test cases, don’t you see now how important too is their work? 👀

The Verdict

There are a lot of more to it on testing than only test automation. There are a lot of testing techniques and variations to learn. Other than automated test, one will also need to consider say CI/CD practices. What good are automated tests if it is rarely used? Or when it is used, it never produces consistent result?

For me automated test is an icing on the cake on top of good testing practices. If our testing practices suck, do not expect test automation to magically solve our problem. We need to fix our testing practices first.

And one good way to start improving testing practices is to start honoring both testers and automated test engineers with the same level of respect. This way everyone understands the importance of both generating good tests and automated tests.

If your testing scenarios sucks, what do you think the output of your automated tests will be?

Leave a Comment