The agile testing model says that there should be one tester per feature team or scrum team, where there are 3 to 7 developers per team. Alan Page’s modern testing says that there should be one quality specialist per team. Usually, that means that testers work full time with same people and on the same functional scope.
Recently, I have thought that there is a serious limit to that organisation. Testers should have a big picture of the product. Their role is to alert about impacts and risks. They should know everything about the application in terms of features, how each one is related to others. They should know how external services are related to it, which action triggers which event (emails, tracking, queues…). They should be able to reproduce all the user journey through the product and be able to answer questions about all its ecosystem — and then themselves ask questions to challenge the needs and the developments.
If they work on the same functional perimeter all year long, they will become blind, or at least short-sighted to what happens around them. They could miss some impacts and regression risks out of their arbitrary frontiers.
Of course, this applies when several teams and several testers work on the same product — and there can be several applications linked around the same product: a shared database, a back office interface, microservices, etc. If testers work in a company with several products not linked or lazily linked, it becomes easy to manage what triggers what.
An alternative way is to make testers change teams periodically, once they know enough about that limited scope. When they have tried all features and feature teams, they come back to the first one and then learn about all that have changed since the last time.
Or testers can work together, on the same bench. They can share practices, ideas, problems, bugs found. They can do pair testing. They can be a team. I know what you are going to say: “Smells like waterfall”. But it is not. Because that not means that developers will “pass to QA” like in the old ages. Testers can still test requirements, design, UX, work in progress, integration and so on. And test together with developers (together means at the same time, at same desktop, at same screen). To detect problems early and shorten the feedback loop. But they will do it as product experts, not features focused. They will think as users do and challenge developers more business focused.
It can add a lot of value. It worth the try.
And what do you think? Do you believe that the best way is for testers to be distributed into teams or not?