0

I've been working as a test automation engineer for almost two years now. As expected, most of my job involves ensuring that the automation (primarily written in Python) is operational and reliable. However, I often find myself performing numerous tasks such as creating and maintaining test cases and test plans, debugging product-specific issues, and writing test reports for Confluence. These tasks take up a considerable amount of time that I could have otherwise dedicated to automation.

Is this a standard expectation for a test automation engineer? I often hear people referring to "automation" as just another tool for a QA engineer.

In the context of my company, however, here's the problem: Our product ecosystem is incredibly vast and complex, resulting in equally vast and complex manual testing and automation.

For instance:

  • Our test automation code base currently consists of over 40k lines of Python and JavaScript code, over 100 Jenkins pipelines each with more than 200 lines of code, and over 30 Ansible playbooks—and we still have a long way to go.

  • Just one of our products has a user manual exceeding 1k pages in PDF format.

Ensuring the automation framework is present and works reliably is a massive task in itself. However, when I also have to consider creating test cases and test scenarios simultaneously, it can be overwhelming. Often, I find myself seeking assistance from our technical support colleagues, manual testers, or studying our thousand-page product manuals just to come up with meaningful test cases and to determine whether something is a bug or intended behavior. I feel in our company the manual testing and test automation are so vast and different, that I can't do neither correctly because I need to juggle both at the same time.

So, is this just the nature of test automation? If so I will seriously consider to switch to a classic software developement position. Or would this problem be solved if we distinctly separate QA engineers from automation engineers, and if so, how?

Thank you in advance for your insights.

Improve this question
5
  • Are you writing manual test cases, or automated test cases? Commented Aug 3, 2023 at 21:09
  • Are you writing test cases for new features, or are you the unlucky person who is backfilling test cases that should have been written years ago when the original development for that feature was completed? Commented Aug 3, 2023 at 21:11
  • Asking things like "Is this a standard expectation for a test automation engineer?" is not a concrete problem that we can solve. I don't think there is a standard here. Commented Aug 3, 2023 at 21:12
  • @GregBurghardt Thank you for the comments. I'm writing manual test cases first for new features. That itself is a huge task. Then afterwards I need to automate them which is another huge task. Sometimes that for old features. I used to think that an test automation engineer is basically just another software engineer, like frontend vs backend engineers. If I apply specifically as a backend engineer, I dont want to deal almost half the time with the frontend. I thought the same would be with an test automation engineer and manual tester. Even more so if the company has a complex product. Commented Aug 3, 2023 at 22:01
  • Are these manual test cases that manual testers go on to execute? Commented Aug 3, 2023 at 23:16

3 Answers 3

Reset to default
2

Each organization draws its responsibility lines differently, and a distribution of responsibilities which works in one organization does not necessarily work for another. So I don't think an outsider can give you meaningful advice if "separating QA engineers from automation engineers" will solve the issue that your current position involves certain tasks you don't like.

However, my experience in our business is that if you want to automate some task effectively and correctly, it is often best to have someone first doing the task manually before thinking about automation, validating that the task is in line with the business goals, and doing a requirements analysis. For this, it does not matter whether one writes programs which automate tests, or programs which automate classic business processes. So before you write a new automatic test, it makes often sense to do the testing manually first, for validating if it is "on track" and brings the expected benefits. It also makes sense to plan and analyse such a test first before implementing it.

If noone else in your organization has the reponsibility of planning, analysing and managing new tests, it will be probably you who will have to do it. If you think that should be someone elses job because you only want to code tests, but not the necessary (and sometimes cumbersome) preparations, you need to speak with your superiors. But don't expect strangers from the internet here to tell you if that will improve your organization's processes or your personal situation.

Improve this answer
5
  • Thank you for your comment. I totally agree that. I find myself often doing requirement analysis and consultation with technical support, which can take me multiple days, just for manual test case. But just purely objectively, do you think there are scenarios within a company where it makes sense to make a hard seperation for these two? And would be a way to do it? Like providing automation libraries with as simple as possible interfaces so that manual testers can write their own scripts, without them needing much programming skill? Commented Aug 3, 2023 at 22:06
  • 1
    @Aki: This is highly dependent on the skillset of the team. Commented Aug 3, 2023 at 23:15
  • @Aki: Just like how the responsibilities between a DevOps team and what is casually called a "code factory" are almost orthogonal, so can the responsibilities of testers be defined in dramatically different ways. For a sufficiently large company, roles tend to be less multifaceted - but that's still not a given, as some companies (regardless of size) will favor cross-functional expertise over "one job" role division. There's just no definitive answer on what the right thing to do is. Commented Aug 4, 2023 at 2:59
  • @Aki: I don't think I can answer this "purely objectively" - but I can tell you my opinion about this, from my past experience, which is probably biased: no, I don't think it makes sense to have a strict separation between analyst and developers (regardless if the team works on tests or business software). That does not mean you cannot have these different roles in an organization, both having a different focus. But it helps a lot when your analyst are also experienced with writing code and can communicate with devs in "their language". Commented Aug 4, 2023 at 6:02
  • ... said that: I fully agree to what Greg Burghardt wrote above: the skillset of the team is the key factor. Let me add that there are many people who think requirement analysis is an interesting job - I am one of them (as long as it does not mean I don't have to do that exclusively) . Commented Aug 4, 2023 at 6:03
2

would this problem be solved if we distinctly separate QA engineers from automation engineers, and if so, how?

Such a drastic change would likely solve your problem by giving you a new problem.

I have worked as a back end dev in a shop that had distinctly separate QA engineers. Thus no one had to juggle designing a manual test and an automated test for the same thing. However, this meant the vast majority of manual tests never became automated tests. So the list of manual tests kept getting longer and longer. So no, we didn't have your problem. Our problem was from when I turned in my code to seeing it shipped took over 6 months. We had that many manual tests. I'd have loved to have you in our shop.

When you turn a manual test into an automated test so trusted that no one performs the manual test anymore you have done a very good thing.

Improve this answer
0

In the end, you and some other people with different job titles, are responsible for tests being performed and passed. That’s the bigger picture.

I would expect that automation is the kind of task that should go first to you, and that you are the best at doing this kind of job. But if there is need for other work, then it is likely that some will end up with you. People will assume that if you can automate tests, then you can design and implement tests to some degree. It should not keep you from doing your job.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.