How to integrate 4 QA engineers into 4 dev (Scrum) teams?



  • In the Product Team I work in, the engineering resources look as follows:

    • 4 dev teams (4-5 members each), each team with a dedicated Product Owner
    • 1 QA team (4 members)

    Approach 1:

    Currently, the single QA team works together in order to manually test tickets coming from all 4 dev teams. This approach is working but it also creates questions about priorities: which ticket of which team is more important to test? how do the dev teams choose a tester to assign the tickets to? etc.

    Approach 2:

    What we are thinking of, though, is assigning 1 QA engineer to each dev team. This, of course, raises the question of truck factor, as having only one dedicated QA engineer to work with a single dev team seems risky and might be inefficient.

    Question:

    From your experience, what would be the most optimal way to integrate the QA team into our product development? Are there any reasonable alternatives to the 2 approaches above?



  • You have Scrum in your tags, so the first point worth noting is that Scrum requires cross-functional teams. I assume QA is required to deliver product to production, so that skill needs to be in the teams.

    Now, with a 4:1 ratio there is a very real risk of them being overwhelmed, especially if all of the work is handed to them on the last day of the sprint. Here are a few things to consider in this regard:

    1) Nothing says a team member from another team can't help if needed. This is a band-aid to the problem, but sometimes a band-aid is exactly what you need.

    2) There are many ways to run development and testing in parallel. I highly advise looking at TDD, BDD, and Spec-by-Example for ideas of how to not wait until the end of the sprint to test. (I know this doesn't cover all types of testing, but it really helps spread the work over the whole sprint)

    3) The value of a good QA Engineer is not in running tests or documenting tests. It is in identifying what to test - the cracks and angles the developers don't think about. That means that a lot of the labor of testing can picked up by any scrum team member.

    4) One of things you definitely lose in this model is people with like skillsets helping each other grow. A simple "chapter" or "community of practice" model that lets testers meet together once a week to share ideas and best practices helps mitigate this.

    I've worked in both of these models as both a developer and a tester. Option 2 always got me better results.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2