I'm looking out for patterns how to more effectively bring QA topics into our agile product development team. One idea is to let one developer do the implementation with TDD (so alongside unit tests) and let some other developer write the integration/acceptance tests. This basically boils down to separation of concerns to eliminate bias and a four-eyes-principle.

So my question regarding this practice:

  • How common is it?
  • What opinions and experiences are there?
  • Pros and cons?
  • Implications?
  • How happy are others with it (QA, devs, POs)?

Personal opinions and experiences but also your favourite articles about the topic are very welcome.

1 Answer 1


Two important concepts should be considered:

1 - Agile Principle #11:

"The best architectures, requirements, and designs emerge from self-organizing teams."

That means that the best way of work should be discovered by the team. That means experimenting, even with practices that seems efficient. Learning and mistakes walking side-by-side and improve the value-delivering as a whole.

2 - Generalizing Specialist:

The member of an Agile project is usually a Generalizing Specialist - someone who has understanding of the whole, is able to talk and discuss all aspects of the software development process. It doesn't mean that this person doesn't have an area of interest (QA, backend, etc), but that he knows how each piece fits on the puzzle.

Considering it, for improving the velocity as a whole, the tasks should be performed by the members who are able to do it (or will learn how to do it), regardless of roles and titles. If in your team the devs are the best people to write some type of test, do it. Teach others to do it as well, so the roles can be changed in the future. The best task-assignment strategy is volatile, since people are learning and changing interest all the time, distributedly.

Regarding the four-eyes-principle, code review helps to spread knowledge, making the work packages more visible to others, including QA.

One strategy that I have find to be very effective is to use planning time to brainstorm what and how things will be test ("Scenario X is for integration using the tool Z, scenario Y needs E2E"). At code review, different people can take a look on how different levels of testing were implementing, enabling them to take similar future tasks in the future.

  • 1
    Re "Generalizing Specialist": I call it "T-shaped skills": thin layer over wide area, and deep in one specific section. Feb 28, 2018 at 15:56
  • thanks for taking the time for your well-thought answer! that's true indeed and we try to handle it exactly like that. nonetheless the scope of this question is if there are experiences and which these were. that way we can learn much more efficiently.
    – nepa
    Apr 26, 2018 at 20:22

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.