We often discuss where the “testing people” fit into the organisation – are they part of a delivery team or an enablement team independently of the delivery teams? The Team Topologies model enables a discussion about this challenge and a guidance on what goes where and why.
I can see the benefits of having a central Test Center of all the testing people – and, on the other hand, having them spread out in the delivery units. I work in an IT services company, sometimes a project does not require full-time test attention. So we work on a range of customers, at the same time. On the other hand, sometimes projects lasts for years and years – and the testing people become dedicated towards a specific company IT stack and delivery team.
Notice that I use the term “testing people” to cover testing specialists, test analysts, automation specialists, test engineers and test managers like myself. Besides the moniker “testers” in the blog title, I try to avoid calling us “testers”. First of all, “testing people” do more than testing and secondly other people do testing too.
The Test Center I’m in is an organisational unit of “test consultants” of various of the mentioned roles working for various of projects. But considering the “whole team approach to quality“, the Test Center unit sounds a bit .. off. Would it be better to assign everyone to a delivery unit? – What would be the reasoning behind what goes where where and why?
I have found the Team Topologies model, which identifies these teams:
- Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain [yellow]
- Enabling team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities [cyan]
- Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed [red]
- Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams [purple]

The model identifies three modes of interaction during the flow of change:
- Collaboration: working together for a defined period of time to discover new things (APIs, practices, technologies, etc.)
- X-as-a-Service: one team provides and one team consumes something “as a Service”
- Facilitation: one team helps and mentors another team
Based on this model the dedicated testing staff should be part of the stream-aligned delivery unit. While everyone working ideally to enable the team – testing coaches etc – should be part of an enablement team, aka. a center/unit/group/staff team for enablement (Accelerate the Achievement of Shippable Quality). I read into it, that the enablement team’s primary focus would be to build self-reliance in the team and get out of dodge. A key principle in Modern Testing.
How “testing people” could fit into the other two teams (Subsystem & Platform), I would have to consider a bit more. The testing activity is in both, and the Enablement team also facilitate (testing) into those two team modes/units. So perhaps it’s not that different. What do you think?
The findings of the model also aligns with the “Product Team” and “Competence Team” of this article (in Danish): Hvilke karakteristika og udfordringer har dit team?
Reality, though, is a bit more complex. Even the Team Topology Model – is just a model, and wrong a some point. It is though still useful in enabling a discussion on where the testing people fit it, and why.
[…] Where Does Testers Fit In? – Jesper Ottosen – https://jlottosen.wordpress.com/2020/06/10/where-does-testers-fit-in/ […]
LikeLike
[…] you can teach the people the details, sometimes you can have a guide (tool smith) to enable them – sometimes it’s best to let the engineers tackle the automation. That depends on […]
LikeLike
[…] Where do everyone fit in? The testers jobs will be to explore and to train/enable the experts. I see more testers and test coaches being in the Enabling team – while the SME’s are the key persons in the Stream-aligned team – especially if the tools available to the SME’s are low-code. Have tool smiths (Test engineers) at the ready with building blocks of reusable components, automation best practices and coding snippets (Complicated Subsystem team). […]
LikeLike
[…] are obviously important to line managers, coaches, lead roles and people in enablement roles. But for the individual contributors in the teams – relations matter too. First of all, time […]
LikeLike
[…] to support the work done within the subprojects – the testing is done by the team members (there are no professional testers). So I need to learn new skills in making this happen, and unlearn some […]
LikeLike
[…] research behind the key drivers of improved deliveries and organizational excellence. Readers of Team Topologies will recognize the need to rearrange the team structures to beat Conway’s law. The book is […]
LikeLike
[…] roles above and the more coaching specific roles. They align fine with being enabling roles in the Team Topology sense. The difference is probably on level the roles play. My role will (also) address delivery […]
LikeLike
[…] aligns with the research of Accelerate (Lean Practices, specifically) and the Team Topologies framework – and with the old saying: If you want to go fast, go alone. If you wan to go far […]
LikeLike
[…] DevRel trend fits nicely with the Enabling teams of the Team Topologies framework. Where we can look at the delivery team as a stream-aligned team, compared to “Testing […]
LikeLike
[…] If it’s for another team to fix, defects are simply something communicated between the teams (check team topologies for team interactions). Sure you can still find a blocker or a P1 – what matters is how fast you can fix […]
LikeLike
[…] often discuss where the “testing people” fit into the organization, Where Does Testers Fit In? […]
LikeLike
[…] usually a team around maintaining the application. To some degree, we could frame these teams as stream-aligned teams. The experts in testing the applications are the superuser – hence they do the […]
LikeLike