Do "Automation Engineers" not have to write Test Cases?

For those of you that are Automation Testers, or that are experienced in using an Automation tool to assist you with your testing, do you still write manual test cases?

Do you believe that Automation Qa should not have to create new test cases prior to automating them, i.e., a separate manual qa team should write the new test cases instead as that’s more in line with their primary duties?

The situation I am asking about involves two different products; Ranorex where the automated tests are written and Test Rail where 800 regression Test Cases already reside and are where the manual test cases are written and maintained.

I’m trying to get a grasp on other testers’ experiences in these types of situations and your opinions on these types of viewpoints if you have them or have run into any other testers with these viewpoints who can maybe shed some light on this for me.


I assume (correct me if I’m wrong) you may be in situation where on an existing project a bunch of manual tests were prepared and now because the manual testing takes a long time, team is trying to automate all manual tests. This is a very common scenario and unlike ideal situation of a new project where there are “no separate manual tests” won’t apply here until all tests are automated.


  • Automation engineers work in silos and take longer to understand application
  • Automation backlog (manual tests) keep on increasing and regression automation on a very stable application is rarely useful. There will soon be too many automation tests which never fail (i.e. don’t make sense to execute all the time)
  • Manual tests are always end to end. This approach forces automation to be end-to-end which is most of the times a bad idea (considering you have 800 cases) and takes hours to execute (instead of seconds/minutes).
  • Automation engineers are often not included in discussion of new features with developers hence cannot foresee changes that need to be incorporated in their automation framework to make automation easier.

(can’t think of many advantages of this situation)

  • Fixed estimate-able backlog? (not really true as the backlog will keep on increasing with new manual tests). If the backlog is fixed that may mean that it’s too late to automate?

Typically, in above situation, if automation engineer is working in silo to just automate what’s written manually then she/he may or may not get right exposure to domain of the application to be able to write effective (new) automated tests. i.e. until she/he gets enough experience by automating existing manual cases. hence he/she may need help/training before he/she can write new automation tests (without referring to manual tests)

In any case, it’s faster, cheaper and efficient for an automation engineer(s) to write new cases (i.e. System Tests instead of Regression Test) and if automation engineer doesn’t have enough application experience then have a Subject Matter Expert (could be experienced manual tester) review automated tests.


  • can explore ways to shift testing left and write smaller and faster API/Unit tests
  • work closely with devs to reduce feedback time
  • save cost
  • provide more value faster compared to end-to-end regression suite of 800 tests
  • and many more…

I really believe that its organization like. It depends on whether you are full-time automation or a part-time one. In my case, I am a part-time automation engineer and I write manual tests prior to automation. I have found an advantage in that automation taught me how to write more quality, more autonomous, and more atomic test cases suitable for both automation and manual testing. This combination gives me the possibility to shape the test suite to contain automation like test cases and those which can’t be automated (at least not with current automation framework - python/selenium). Also, it gives me the opportunity to help and shape newcomers in the testing world. Currently, I’m happy with that…


Considering the value of the work (for the organization), the main consideration with me would be how good people are at either the testing side or the automation side. These are (completely?) different skillsets. Being an experienced automator, I have had testers come over and work on automation that I would really, really like to stay far away from it. Just like I know plenty of programming people are not good at defining good test cases, and some never will be.

While having people learn new skills is great if its adds value for the organization, we all have different talents. So if it turns out someone becomes good at testing or automation: excellent! But if a good tester turns out to remain a lousy automator, it is normally better to stay in testing, and similar for a dev or an automator whose testing adds little value. People who do what they are good at seem to be more productive and deliver higher quality work. That is usually important.

That being said, I would think it always pays off for someone to have an understanding of ‘the other side.’ So it is good for a tester to get a grasp of programming, even if it is better left to devs. Similar for automators understanding testing. It boosts understanding of each other and facilitates communication, which helps working together toward the common goal of a product that supports business interests.

1 Like

Hello @tech4ever1!

Team members who create and support automation must, very definitely, understand how to write test cases. Without that understanding, in my opinion, the automation would be suspect, may be invalid, and could provide invalid results. That is, the automation could be little better than buggy code.
Should team members who create and support automation write test cases? I believe they should. Writing automation without an understanding of the test’s information objective is like writing a program without requirements. It may work but there is no value to it.



Hi, Adrian!

Everywhere I´ve been testers were assigned to a functionality or project and similar, I had to do everything related to what I was assigned: writing the Test Cases, Automation and performing Automated and Manual Test Cases or Semiautomated.

Actually there were moments when I “inherited” Test Cases already written for some reasons and I had to do the automation or perform the tests and I hated it and tried to speak with the managers several times to stop that. I feel in experience that the mindset of someone who writes a Test Spec and it´s not going to be automated or performed by that person might not be the best one, I saw many Specs not finished, not explained, organized not for the best automation, with errors or no specific data. I´d say that most of the times I actually had to modify/redo the Specs. So in my opinion, I´d rather write them myself even if the main task is automation/execution.

The only thing similar to that was in one company where there was a test tool team and then my team, testers. The test tool would configure the framework and support us doing the test automation but we were doing everything: writing the tests and automation, they were just working on the framework, which doesnt seem your case.

So what do you think yourself?