Folks who test software are called “QA” in my corner of the world. QA. Quality Assurance. They’re meant to assure that the software has some acceptable level of quality before it ships. The definition of “acceptable” varies, depending on the product, or the feature within a product. QA is meant to find the bugs, the defects in the software, before the users do, so that the software developers can fix them, before the products ship.

I was in QA once. For about six years, I relished the work. There was the thrill at finding just the right sequence of steps to bring a piece of software to its knees. There was the challenge of figuring out how to reproduce a bug, so that the developer and I would know when it was really fixed. QA fed my creative side, too, when I figured out how to automate tests, so that the computer would find bugs for me, much faster than I could, without getting bored by the repetition.

But there was the dark side, too. When the developers didn’t finish their work on time, our QA schedule would be compressed, overflowing into nights and weekends so that the company could ship the product and make its revenue numbers. Sometimes a hard-won bug report would be marked “Will not fix”, or “Cannot reproduce”, or “Fixed in the next release” — what a let-down. It seemed like QA was always standing in front of a train. Between the developers and the marketing and sales folks, QA seemed like an obstacle rather than an asset.

You’d think that the support folks — the ones who listen to the angry customers — would be on the side of QA. But no. I complained once about a down-sizing of the QA team to a support guy. I’d been in support before I was in QA, and I expected a sympathetic ear. But he had a different view, “It doesn’t really matter. You won’t find all of the bugs. We’re going to have to patch it no matter what you do.” Those words cut me to the core.

So after six years in QA, I changed careers. I became a program manager, and I led the teams that shipped software out the door. I ran the trains, but I tried very hard not to run over the QA team or the support team in the process. Instead, I tried to promote dialogue between QA and support and development and marketing, to achieve the optimal balance between quality and timeliness and feature set. I ran trains for another six years, before moving into the ranks of the bureaucrats.

I may not be in QA anymore, but I still have QA in my blood. Every so often it crops up, like an outbreak of the shingles. I’m using a piece of software, and I find a bug. And off I go, figuring out how to reproduce it. Figuring out how to work around it. Filing a detailed bug report so that someone else will know about it, maybe fix it, or at least tell someone else how to work around it, too.

Unbelievably, last Saturday, I found two bugs in Quicken. Quicken Premier 2008, to be exact. How many b-jillion copies of Quicken are there on the planet? Its quality has to be primo — this is people’s bank accounts we’re talking about. The bug wasn’t in the check register, though. This bug was in cashflow projection: if you had a paycheck that deposited into multiple accounts, or a regular transfer between accounts, Quicken would project the wrong account getting the money. Your cashflow projection could show you in the hole, or with buckets of cash, and neither would be right.

Yeah, I should report the bug to Intuit. With the workaround. When I get a few minutes to figure out how. But I wonder, did they find this bug in QA? Was it marked “Fixed in the next release”? Did they think about the poor sod like me who would spend hours on a precious Saturday, trying to figure out the bug and how to work around it? But then, I used to find bugs for a living. I can’t really blame Intuit for the QA in my blood.