Quality is a team sport – why software testing is not an individual discipline

As a former water polo player, coach of a Hamburg women's Bundesliga team, the national deaf team and assistant coach of the women's national water polo team, the wet element was my absolute passion for many years alongside my profession.

A common metaphor from team sports illustrates this: in competitive sports, it is rarely a single person who decides victory or defeat. Even exceptional talents are embedded in a team of athletes and members of the support staff. Quality in software development works in a similar way. It is not a solo performance, but the result of a well-coordinated team.

This blog post shows why software testing is a team sport – and why passionate testers in particular play a central, connecting role in it.

Myth: ‘Testers find bugs, developers fix them’

The classic but outdated idea is that developers write code, testers find bugs, and then they are ‘fixed’. This image reduces software quality to a linear sequence of activities – and to individual roles.

In practice, this misconception leads to:

• silo thinking,
• late recognition of risks, and
• unnecessary tensions between roles.

However, quality does not arise at the end of a process, but in every decision, from requirements to design, coding, and the obvious, testing. Testers are not ‘quality control on the assembly line,’ but part of the whole game.

Team sport vs. individual sport

Individual sports thrive on individual performance, while team sports thrive on coordination, trust and communication. Applied to software development, this means that

even the best tester cannot ‘test away’ poor quality if requirements are unclear or technical debt is ignored.

As in team sports:

• A pass is only as good as the teammate who receives it.
• Tactics are more important than individual actions.
• Success is the result of joint preparation.
• Software quality benefits from precisely this interaction.

Comparison with team sports

In a water polo team, there are centres, defenders, halves, outsiders and, of course, the goalkeeper. However, none of these roles is more important than the others – they have different tasks but still pursue a common goal.

Applied to the quality team, this means:

• Developers ensure clean, maintainable code
• Testers question assumptions and discover risks
• Product owners prioritise technical added value
• Specialist departments contribute usage perspectives

Only the interaction of these roles ensures that the ‘game’ is won – in other words, stable, usable software is created.

The roles in the quality team

• Tester role: You think in terms of risks, usage scenarios and deviations. You bring curiosity, scepticism and structure to the process.
• Developer role: They contribute significantly to quality – through clean design, code-level testing and early communication.
• Product owner: They provide clarity on goals, priorities and acceptance criteria, thereby directly influencing testability.
• Specialist department: The specialist department provides context, realism and valuable feedback from the user's perspective.

Shared responsibility

Quality is not a handover from A to B, but a shared responsibility. If an error is discovered late, it is rarely the ‘failure’ of a single person – but rather an indication of gaps in the interaction.

Shared responsibility means:

• Clarification in early stages instead of escalation in late stages
• Transparency about risks
• Respect for each other's perspectives

What passionate testers contribute

As the interface between development and product owners, testers need a deep understanding of the application. This includes both its strengths and potential weaknesses in order to enable an objective and holistic evaluation.

Moderation: They moderate discussions about quality, risks and priorities – objectively, connectively and solution-oriented.

Asking questions: Good testers are not necessarily ‘black painters’; they ask the questions that others overlook:

• ‘What happens if ...?’
• ‘Who is this actually for?’
• ‘What is the risk if we deliver it this way?’

Making quality visible: They make abstract risks tangible – through examples, scenarios and understandable communication.

Practical examples of testing in a team

Pair testing

In pair testing, two people test together – often a tester and a developer or two testers with different levels of experience. This promotes knowledge transfer, mutual understanding and faster insights.

Shift left / shift right

• Shift left: Testers are involved early on in refinements and design discussions.
• Shift Right: Quality is also monitored after release (monitoring, feedback, logs).

Both approaches strengthen team spirit and reduce surprises.

Conclusion

It can be said that developers should not rely solely on downstream quality assurance. Instead, it is crucial to keep an eye on the technical requirements during development. This leads to higher code quality and significantly more efficient feedback loops.

Good software is not created by heroes, but by teams (early, together and purposefully). Software testing is not an individual discipline, but a team sport in which communication, trust and shared responsibility make all the difference.