I understand that preparing test cases and scenarios that goes through the whole system stack should be written by a QA person. But my question is with automating these tests, and I mean specifically e2e tests. Who should be responsible for the implementation of e2e tests, is it developers? or qa engineers? and why?

  • 1
    Why do you believe that "preparing test cases and scenarios that goes through the whole system stack should be written by a QA person"? I do not believe that to be generally true. However, let's assume that it is true. Who is responsible for executing those test cases? Now consider automation as a form of execution test cases. If automation is execution, who should be responsible for automation?
    – Thomas Owens
    Commented May 8, 2021 at 23:57
  • 1
    QA has its own set of skills, and writing test cases to cover all possible considerations of a specific feature is one of these skills that is not necessarily as sharp in a developer. I also believe that the answers to your questions is also QA person. So QA person should write test case, execute it (manually or automated), and then report to devs if needed. This is the full QA cycle as I see it.
    – Sisyphus
    Commented May 9, 2021 at 9:34

2 Answers 2


Test automation can be as complex as writing the application it tests. How you write automated tests determines who writes the tests, because of the different skills involved.

If using a GUI tool to create tests, programming skills become less important. This increases the number of people qualified to write these tests, which usually means "not the developers or QA automation engineers." This tends to be done by manual QA testers who have fewer technical skills.

If practicing Behavior Driven Development, a business analyst or product person writes the tests in Gherkin. Developers or QA automation engineers would create the testing infrastructure code that implements the Gherkin step definitions.

You can, of course, write the test cases in whichever programming language your team is comfortable with. Developers or QA automation engineers would then write the test cases and infrastructure code for the tests.

Who writes the automated tests depends on the skill set your team has and how you choose to write the tests — and how you choose to write the tests depends on the skill set of the team.


The idea that a QA person must prepare test scenarios and cases and then execute those cases is not generally true. Although some organizations are structured this way, only a small number of the most critical systems require a dedicated QA person to do this type of work, and even then, the trend is to have others do this as well with the QA team providing an extra layer of security and to meet compliance rules.

For the vast majority of development, the team, as a whole, should be responsible for quality activities. It may be helpful to have various QA specialists - people who have special skills around analyzing requirements for testability or identifying test cases or exploratory testing or test automation frameworks - on the team. However, the existence of a specialist doesn't mean that all of the work must be done by this individual. Instead, they exist to teach the rest of the team how to have these skills in sufficient amounts to be able to produce a quality product and to review the work of people who may not be as proficient in these areas.

Unless you have specific regulatory constraints, I would suggest that anyone who is a developer should learn the test automation framework and tools and be able to write automated tests. In a larger organization, it may also be useful to have a team (or perhaps the team of QA automation specialists attached to development teams) ultimately responsible for decisions pertaining to the test automation tools and frameworks, but that doesn't mean that they are responsible for creating and maintaining all of the automated tests.

I would also point out that just because the ideal state is that the developers help out, to some extent, with test automation doesn't mean that your organization can support this. Some organizations aren't set up to have cross-functional teams in this manner, especially if the performance of the developers is measured by shipping features (or bug fixes). There could be shifts at an organizational level needed to enable this kind of collaboration and whole-team mindset.

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.