Wednesday, April 1, 2009

Reporting Structure

Someone asked me this today: how do you structure a QA team? Let's talk about some background so this question makes sense.

The Scenario
This is an "agile company" and they have approximately 16 developers. There are no testers yet (they're hiring), and they're bringing in one QA manager. They're splitting into teams of total size between 5 and 8 people and following basically a SCRUM model.

The Question
So the question is how should the reporting structure work? Is QA part of each team? Is QA a separate team?

Let's Think About This
There are two basic schools of thought here that I can see. The first thought says that in a SCRUM (or agile or agile-like) environment everyone's on the team, and that means the testers are on each team. The second school of thought says that testers are a bit special and that they should be on a separate team.

We are all one team
  • Team means team, not "team, but...". The whole team, including the tester, should be aligned in focus and goals. This also fosters increased trust among team members, a "we're all in this together" mentality.
  • Depth of product knowledge. Having the tester constantly with the team gives that tester a deeper insight into the product or portion of the product he's working on. Focus provides depth, and that means you'll test the product better.
  • More likely to hit goals. If your tester is dedicated to your team, then there's less chance that your team will miss a goal because your tester had to do something else for another team. A dedicated resource - any dedicated resource - is less likely to fail.
Testers are a team
  • Bus factor goes up. If you have a test team, you have a group that can back each other up. John is sick? No problem, Matt can test that feature today. This doesn't work if there's one tester per team, and this is huge across vacations, illnesses, and testers eventually leaving.
  • Discipline thinking. Being around other testers, talking to other testers makes you a better tester. If you're on your own surrounded by developers, your test thinking and techniques are likely to get stale.
  • More flexible coverage. Not all projects have the same testing needs, or even the same level of needed testing, at all times. So one dev team may have very few testing needs while another dev team may be in a heavy testing point. With a test team, you can scale up and down with teams by simply shifting resources.

Bottom Line
The bottom line is that it depends on your situation.  I think it can work to put testers with teams (option "we are all one team") if you:
  • have a group of strong, confident testers
  • foster cross team communication so testers continue their discipline-specific communication
  • have large enough teams that you have more than one tester per team
If you don't have those factors, then in general I would err toward creating a test team and having testers work generally but not exclusively with a given development team.


  1. Two more points:

    With an integrated tester there's more cross-discipline transfer -- programmers learn to think about testing.

    With a separate test team, it's more likely that they will have a larger picture of the product that the separate component teams.

  2. starting line you are saying about some company who is hiring tester's.

    please e-mail me that company details.

    my e-mail id is-