QA! QA? We don't need no stinking QA!

After nearly 30 years as a professional programmer I am still truly astounded every time I see, hear, or experience a lack of understanding of the importance of QA in delivering products.

Just two minutes ago I tried to create a new application in iTunes Connect (a new iOS gameI am still working on), hit save and voila - a nasty error with a helpful email link which uploaded a lengthy java stack trace terminating in a NullPointerException! An application used by half a million people to create new iOS and OSX applications and yet I get the most idiotic of Java exceptions. In this case they were attempting to perform a regex on what I imagine was an empty field.

I once worked for a financial services company where the in-house customers complained that QA took too long to test their applications so they requested that IT skip QA entirely.

A story I heard once about the early Netscape was that they hired 100 programmers before they hired their first QA engineer. Might be apocryphal but given the quality of those early browsers it wouldn't be surprising.

My current employer which has an MMO has no QA at all, other than ad hoc testing by a random few. The customers finds all the bugs and complain, which then get ticketed, and often ignored for years. I think this is fairly common in small companies who perceive that QA is an expense they can't afford.

I once worked a short contract at Lotus on the Mac version of ccMail and doing a little digging into crash reports found that the lower level out of memory handler was never being called, causing the client to crash under memory stress. This had been happening for several releases but QA either failed to follow up on the user reports or never did any real out of memory testing. QA is not about being nice but kicking Assurance.

So why do people skimp or even skip QA?

• QA is seen as an expense not an asset
• Programmers are thought capable of testing their own code
• QA is something you do at the last minute before shipping
• Better development methodologies mean less need for QA
• Rampant stupidity by management

QA means Quality Assurance, a fancy terming meaning assuring that your shipped or production application works correctly and avoids making you look like an idiot. QA is not something you give to the new intern to do, or grab a few office workers to bang on the application for a lunch hour. It is a real engineering discipline where ability and experience make a difference, just as in programming the application.

During Deltagraph development in 88-93 we had an in house QA person who had a magical ability to find bugs all day long even in code the programmers were sure was perfect. The publisher's QA person was equally capable of catching whatever bugs she missed, and both were persistent in badgering the programmers to fix the problems and following up to ensure no new bugs were introduced. Since these were the days of shipping on 10 floppy disks and a $10 cost of duplication and shipping we had one chance to ship each major version (Deltagraph had 100,000+ customers) so it had to be good. We never had any major issues that required expensive reshipping (ah the days before the internet) and it was a testament to their ability. We had at first 4 programmers and then later as many as 7 with the two QA people, a good ratio.

Today a lot of people feel strongly about banks of unit tests, or even test-first development, both modern ideas. No matter what you choose to do, you can't do with less QA no matter how confident you are about your code. I know management people who think that because there are thousands of unit tests run daily, that QA isn't important. Don't fall into that trap, not matter how extensive your low level tests are, they are no substitute for user level testing. After all the users won't be calling your methods directly but pushing your buttons!

QA is never something you do at the last moment, as in the classic Waterfall. To me the day your application does anything useful is the day QA begins. QA then continues until the application is shipped or put into production. Finding and fixing a bug is always easiest when done soon after the bug was created. Waiting until the last second, even with instant internet updating or server pushing, is likely to result in less quality not more. Fix early, fix often!

Even the best and brightest programmer will be unable to find all of their bugs. After so many years I have made every imaginable bug and feel quite confident about the quality of what I deliver. But I will never have perfect code (although I do have a couple stories...) and can think of tons of times when I let a howler get to QA.

Vitamin QA is a nutrient your product needs every day. Your customers will be happier and your bottom line healthier.

Now pardon me I need to send a bottle to Apple...