QA Journal — Entry 007
On the difference between testing the software and assuring its quality
Someone called me "the tester" today and I didn't correct them, but in my head I did. Testing is something I do; quality is the thing I'm actually responsible for. You can test a feature a hundred ways and still ship something nobody wanted. QA — quality assurance — is the bigger job: not just "does this work?" but "should this exist, does it solve the real problem, and will it keep working when nobody's watching?"
Photo by Jakub Żerdzicki on Unsplash
How a QA brain runs the check
Does this do what the spec says — and is the spec itself even right?
Works once, or works the hundredth time after three other features changed?
Whose definition of "done" are we using — engineering's, design's, or the user's?
Is the bug in the code, or in what we decided to build?
If this passes every test and users still hate it, did we actually succeed?
What am I assuring here — that it functions, or that it's genuinely good?
WHY IT MATTERS
Testing finds defects; quality prevents them 🟡
Testing is a flashlight you shine after the fact; quality assurance is the set of habits that mean fewer things are hiding in the dark to begin with. A team that only tests is forever catching mistakes at the end. A team that assures quality builds so that fewer mistakes are possible — clearer specs, smaller changes, earlier questions. I'd rather kill the bug at the whiteboard than catch it the night before launch.