9

After regularly seeing job openings for "QA automation engineer", I wonder why this role is so prominent? (I deliberately assume a specific view in this post, hoping to get interesting replies.)

I feel like this role is inevitably destined to make itself redundant within a typical shift-left, cross-functional team. It has been my experience several times: as part of the process improvements, the test automation responsibility is delegated to the developers (or whole team) in increasing measures. Which is by itself a good thing, but over time the workload slowly diminishes for the QA automation engineer.

Considering a few things:

  • Who? Having a dedicated role is likely to lead to knowledge gaps (developers write unit tests, the automation engineer tackles whatever follows in the pipeline). That's a silo to avoid. Isn't it preferrable to have the developers write as much of the testing as possible, so they are all aware how/when/what when it comes to automated (and failing!) tests.
  • When? Eventually a shift left is in order (where possible, for somewhat stable features). Why shouldn't the developers also write integration or API tests for their (new) features? More bugs are prevented, and the test runs are kept green. Also the accountability is equally spread among the team.
  • How? A decent developer has at least the same coding skills as a decent QA automation engineer (which aren't necessarily former developers). So this is no reason why developers can't write testing libraries and tests.
  • What? A fair point would be the testing mindset: what should be automatically checked? However, I believe developers can be supported by any QA already in the team (even non-technical), with some minor research, to determine which cases to automate. Collaboration improves and a QA perspective is consulted, even if the developer does the coding.

However, I can see advantages for this separate role, but also with counter arguments:

  • Tooling: a person already experienced in test automation is more aware of the available tools and their (dis)advantages. However, if the team can't decide after researching, I'd still prefer a consultant to set up the most adequate tooling rather than add a long-term role to the department.
  • Tester mindset and common sense: applying the correct mindset has already been addressed aboven. Also, while a developer might write fancy code that is totally overkill for the task at hand, testers are often more realist in this regard. However, if the developers are unable to write a decent (and easy to use) testing library, they're probably not the best developers around. Unless they like making things difficult for themselves.
  • UI and regression testing: this is the one thing that testers often handle once a feature is up and running, and stable. While perfectly acceptable, there is in essence no reason why the team as a whole can't handle this rather than one person.
Improve this question
5
  • 4
    Developers shouldn't test their own code for the same reason an author shouldn't proofread their own writing. Also, at least where I work, the development team developers are always busy writing new features, and the QA team developers are always busy writing new automated tests for the new features.
    – Aaron F
    Commented Feb 23, 2022 at 11:59
  • @AaronF true, but I counter that by saying QA pairs up with dev to determine the test cases to automate.
    – FDM
    Commented Feb 23, 2022 at 12:06
  • 3
    The way we do it where I work is that the architecture team will define the use cases, the QA team will read the use cases and define the test cases, and the development team will sign-off the test cases. Then there's a test review with all parties plus the product owner to ensure everyone's in agreement. I think it's important that QA determines the test cases themselves rather than pairing with development: if they paired up for that task then development, knowing the implementation, might lead QA down the "happy path" and cause them to miss things which they might otherwise have thought of.
    – Aaron F
    Commented Feb 23, 2022 at 12:36
  • 1
    Sounds look a neat process! Agree with your last part too, but pairing up doesn't have to equal a white box approach (for writing out test cases). Thanks for the input.
    – FDM
    Commented Feb 23, 2022 at 12:45
  • Isn't QA the job nobody wants? There's like a 100 questions on The Workplace saying, hired to do this thing I wanted to do, but now they got me doing QA....
    – Mazura
    Commented Feb 23, 2022 at 20:13

3 Answers 3

Reset to default
13

Having a specialist is not antithetical to having a cross-functional team. In fact, I'd say that having specialists embedded on the team or within a team-of-teams can help to promote cross-functional teams by making access to specialized knowledge easier to obtain and share, developing the skills of others on the team.

You do need to take active steps to make sure that the automation engineer is not a silo, but having an expert in test automation can help the other people on the team to learn test automation skills enough to be effective contributors and to share the workload. At the same time, there are specific test automation tasks, like regular maintenance of the tools and infrastructure or evaluating and introducing new tools and technology, that can be best supported by having a single, highly skilled and knowledgeable individual.

I've also found that having a specialist can help to set expectations for the role. Although it shouldn't prevent someone from going outside of their role, and this kind of limiting can prevent a cross-functional team from forming, it does help set expectations on what the primary responsibilities on a day-to-day basis is. Someone in a "developer" role probably expects to spend the majority of their time doing work like understanding requirements and then designing and building solutions, so selling someone on a "developer" role and then putting them into a position where they are spending most of their time maintaining CI/CD pipelines, test automation tools and frameworks, evaluating test failures and making updates, or automating test cases would be misleading at best. On the other hand, advertising the position as a "test automation engineer" and then allowing them to expand into other roles like teaching or developing or manual testing to support the team helps to build cross-functionality.

Improve this answer
2
  • Good reply, thanks. As for your last paragraph: isn't that part of the problem? Developers roles not including the necessary testing to be done on their end? Just like testers need to adapt to modern development life cycles, so do developers. It won't necessarily consume most of their time.
    – FDM
    Commented Feb 23, 2022 at 6:49
  • @FDM It could. It all depends on how the organization defines these roles, starting with postings on job sites and how it's explained when interviewing candidates. Involving the current staff with changing roles and responsibilities as the way of working evolves and being clear up-front with candidates is important for expectation-setting.
    – Thomas Owens ♦
    Commented Feb 23, 2022 at 15:38
10

I think these roles often end up being quality advocates/coaches, more than someone who's automating test cases. This often encompasses several hats, not just the typical QA role, but also devops to optimize the CI/CD system to integrate the automation/make it run consistently/provide useful feedback to devs, coaching devs to own quality and write tests, bring the test mindset to the forefront, etc.

That being said, I think the prominence of the job postings are more a symptom of the fact that many companies are in some weird agile-fall environment, where they think they've shifted left, but don't realize that having distinct test and dev is keeping them on the right.

Improve this answer
0
7

Who do you want looking for bugs ? A developer that wants to get the product out the door and work on something else, or a seasoned QA veteran that has an appetite for finding business critical bugs ?

Having developers and QA work together to decide WHAT to automate is a great first step. Why not take it a step further and have the developer write a test framework and teach the QA person how to write tests ? Teach someone how to fish...

Your tooling argument makes me a little concerned. It sounds like you work in an environment where nobody can make a decision or create a framework. Are your developers writing unit tests for their own code ? Maybe you are already in trouble and need a consultant to come in and "choose a tool" for you ?

Improve this answer
2
  • Thanks for the reply. To me, automated testing isn't about actively looking for bugs. Instead it's about providing a safety net when future changes are happening. Of course, sometimes bugs are found when writing a test (hey - this test fails but everything looks okay?!) - all the more reason it's cheaper if a developer finds it before it reaches the testers.
    – FDM
    Commented Feb 24, 2022 at 6:57
  • Of course, it is always better to find bugs earlier in the process. In an ideal world, anyone on the team should be able to write and/or execute tests (developer, QA, devops, etc). Developers should write unit tests for their own code, they should test their code before passing on to QA, but they should not be responsible for acceptance testing their own code (hey --- it works on my machine !!)
    – ToastMan
    Commented Feb 25, 2022 at 17:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.