← Back to principles

QA

Whole-Team Testing

Statement

Quality is not a separate phase or the sole responsibility of QA engineers. It is a mindset embedded into all.

What this means in practice

Quality is a shared responsibility across the whole team. QA defines clear practices and standards that the rest of the team can follow, but testing and quality checks are not restricted to QA.

A story is only "done" when it meets acceptance criteria and passes the tests the team agreed up front.

Defects are treated as opportunities to improve the system and the process, not as a way to assign blame.

Why this matters

Treating quality as a whole-team concern reduces bottlenecks, shortens feedback loops, and increases the chance that work is genuinely complete within the sprint.

It also prevents responsibility for quality being pushed to a single role, which improves delivery predictability and reduces escaped defects.

Practices that meet this principle

  • QA engineers define the practices and standards that other team members should follow.

  • Not all tests are written or executed by QA.

  • Anybody on the team can execute tests.

  • Anybody on the team can create test cases.

  • Test cases are created in a structured way that supports Given/When/Then and shared standards.

  • Provide training on how to create good test steps.

  • Collaborate across teams on guidelines and standards.

  • QA engineers act as mentors and coaches.

Validation

A team meets this principle when:

  • Story “done” always includes meeting acceptance criteria and passing the agreed tests.

  • Testing is routinely executed by multiple roles, not only QA.

  • Test cases are created collaboratively and follow agreed standards.

  • QA time is used to set standards, coach, and improve the system, not to act as a gate at the end.

Common failure modes / blockers

  • Resentment to change or a belief that quality is "someone else’s job".

  • Over-reliance on QA due to lack of confidence or training in writing/executing tests.

  • Poor quality test cases being created, leading to a temptation to revert to "I’ll do it for you".

  • Concerns about time, such as "developers should be developing" (which can reduce shared ownership if not addressed).