Make Testing a Non‑Event
Quality as everyone’s job. Yet, most of the established teams I’ve joined over the years have dedicated people that take some of the responsibility of QA from the others.
It sounds like a strange way to organize a team when we hear it described that way.
When there is a QA phase, then it should be the norm to hear that “Everything works.” And in those rare circumstances when QA finds a fault, the builders should ask, “What in our process let this slip?” and fix that process so that next time QA will find nothing.
But better still, QA shouldn’t be positioned at the tail-end catching problems that slipped through. Instead, QA specialists should be freed to ask harder questions and drive quality earlier. And shift their focus and energy onto the Acceptance Tests, TDD, and Continuous Integration so that feedback is immediate and defects are prevented, not hunted.
When tests are reliable and fast, refactoring and change become safe, and the subject of QA becomes melded into the system rather than acting as a final gatekeeper.
Discussions for the team
- How do we respond when QA finds a defect?
- Are there some common tests which can be automated?
- Where are the earliest stages for us to bring in QA focus?