Test Team Structure


(Andy Carrington-Chappell) #1

It looks as though we (the test team) may be about to undergo changes. Changes being implemented post a company wide review of testing.

Rumours have it that a new QA function may be formed, and testing would fit into that.

Just for my own reference, how are your teams structured, and what have you found to be the most effective structure for test teams?


(Jesper) #2

I prefer centralized, so that the competencies are under the same manager and you can collaborate on skills building with-in the team. From there you work out into the projects to deliver testing on the long or short run. This is what I see for other IT skills too, a team for developers, a team for Citrix, a team for security etc.

Others dread the “test centers” and successfully establish “loose communities” (Spotify model). Though not under the same manager it can be hard to prioritize shared needs/skills/conferences - as the focus is the delivery teams. If there is less need for a testing specialist in the team, this might be the route.

It seems though like ebb and flow, organisations centralize and decentralize over the years. :slight_smile:


(Andy Carrington-Chappell) #3

Thanks @jesper, really appreciate your feedback. I know some of the more ‘funky’ companies have lent towards decentralisation (Microsoft and Google to name two).


(Jesper) #4

so how “funky” are you :smiley:
we’re not (YMMV) but we also do other things than consumer-focused systems.


(Mark) #5

Even with the Spotify model, testers still form a ‘guild’, which could be a centralised team. I’ve worked that way before.


(Elizabeth) #6

This is a really interesting topic. I’d be keen to hear thoughts on product based test teams for an organisation with several different projects/products to deliver, often to parallel/overlapping delivery timescales. Does it make sense to have a centralised test team in that case? If fixed project-based testers are in place, whats the most pragmatic of cross-pollinating knowledge without taking an eye off delivery?


(Jesper) #7

The test center I’m in is somewhat like that. On the other hand, while we do projects for companies and public service organisations, we do not have “software products” we sell. But we do have 4 year plus contracts to maintan/ develop something, so sometimes it feels like “our product”.

I think you are right that Consultancy vs Product “house” is one of the key differences wrt test team structure.


(christian dabnor) #8

We are a loose team whose members are spread amongst squads. However, I have recently been given the role of Head of QA. As such, I see my role as including the following - being an advocate for quality by promoting discussion, and for the team (as we’re spread around the company, our voice is often lost - I make up for this by being noisy), working with the directors on coming up with an enterprise level goal (which is currently “working towards a zero defect company”) and looking into strategies to get there, and trying to find ways to help the team enjoy their job more, by identifying what areas interest them more and trying to get them assigned to those projects would suit them more.


(George) #9

When you consider the variety of software products and services to develop, there are good arguments to be made for different organizational structures. I’ve worked in development organizations that were either project oriented or functionally oriented. Start-up projects would have one team comprising developers, testers, and a few systems engineers/project managers. The rationale included flexibility and closer collaboration in the team to make up for the lack of institutional knowledge about the new technology. Larger, more mature programs would organize around functions: coding, testing, infrastructure. This functional orientation was for efficiency, improving skills, processes, etc. Of course hybrid structures and matrix organizations can be variations on these. I had a VP who summed up the tradeoff with a gloomy but memorable line: Project oriented teams do the right thing the wrong way. Functionally organized teams do the wrong thing the right way.