Make Testing a Non‑Event
In our day to day lives, the quality of our efforts are our own responsibility. Yet, in most software teams there’s a dedicated group of special people to take some of that responsibility away from the others.
It sounds strange to 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?