The QA Mindset
Michael Lopp, writing over at his fantastic blog Rands in Repose:
My first job in technology was a QA internship. The summer between my freshman and sophomore years, I tested the first release of Paradox for Windows at Borland.
As an intern, I started by following someone else’s QA test plan – dutifully checking each test off the list. After a few weeks, I knew my particular area inside and out. A new build would show up, which I’d install via 3.5-inch floppies, and in ten minutes of usage, I’d have a sense – is this a good or bad build?
In QA, there is a distinct moment. It comes once you’re deeply familiar with your product or product area; it comes when you’re lost in your testing, and it comes in an instant. You find a problem, and because of your strong context about your product, you definitely know: Something is seriously wrong here.
Anyone in the IT/software industry will relate to this. Before MIPRO, I worked in product management and strong QA employees were absolutely invaluable to releasing on time and with full functionality. Sadly, QA is often cut when crunch time rolls around, and in my experience, that’s a gigantic mistake.
My concern is that the absence of QA is the absence of a champion for aspects of software development that everyone agrees are important, but often no one is willing to own. Unit tests, automation, test plans, bug tracking, and quality metrics. The results of which give QA a unique perspective. Traditionally, they are known as the folks who break things, who find bugs, but QA’s role is far more important. It’s not that QA can discover what is wrong, they intimately understand what is right and they unfailingly strive to push the product in that direction.
I believe these are humans you want in the building.
Exactly. A good QA engineer is worth every penny.
