Quality assurance and testing are often confused in the digital world. People often talk about QAs being the people who test, and debate the merits of whether QAs should exist as a role separate to that of developers. But prior to that I find it’s important to distinguish between quality assurance and testing, so here are some thoughts I recently jotted down on the subject.
Testing happens at the end of the process. The developer says “I’ve just completed two really hard days of coding.” And the tester replies, “Thank you. I will now proceed to tell you all the mistakes you’ve made…”
Quality assurance starts at the beginning of the process and happens throughout. The developer says “I’m just about to start this story.” And the QA responds, “Great—did you sort out a design with our architect, then?”
Potentially the quality process also extends (back) into ensuring the right products get built in the first place. This includes ensuring business cases are objective, user needs are adequately understood, and so on.
If we improve our quality process overall then it impacts what we do and don’t need to test at the end. I wrote about similar matters in 2008.
QA is therefore a really big role, and is something that can benefit from a dedicated person leading it. I’ve found really good testers often want to get into the QA side because it helps them address the recurring problems they see.
Mind you, it’s not trivial getting the right person in place—someone who will genuinely be respected by the rest of the team and who will balance process with productivity.