Does QA Matter?

Marc Hedlund on the O'Reilly Radar has a write-up of software development practices he keeps running into at Web 2.0 companies.

Most of them make good sense.  Except one.  He says he's seeing a lot of start-ups with no QA team.  Even worse, it sounds like a bunch of start-ups have convinced themselves that this budget-saving measure is actually the right way to go.  The rationale seems to be that developers will be more careful if they know they're doing their own QA, and since the web-based software can be delivered to users transparently then users can find the bugs.  Why fix anything that wasn't found by a user?

Ahem.  Since I work in a security software company, let me state the most obvious:  if you have security problems in your software, you're better off catching them before your users.  And data corruption too ... imagine if Typepad introduced a bug that when I was trying to write a post I could accidentally delete my entire blog?  Or doing something to my blog could damage someone else's blog?  I sure hope Typepad has a QA team (and I bet they do).

And what if the user finding the bug is a product reviewer, or a key decision-maker at a potential customer?  Again, it pays to find and eliminate key problems before users find them.

Does QA matter?  Of course it does.  While some start-ups may decide to live without a QA team for awhile (something I wouldn't recommend having been through a few start-ups myself) that shouldn't be taken as some breakthrough in software development driven by Web 2.0.  This isn't new.  Lots of software start-ups have been under-investing in QA for a long time, and often with a similar sour grapes rationale -- "we can't really afford good QA (either in money or time) but we realized that we don't really need it."

The idea that developers and users can provide sufficient QA is dangerous at best.  Expecting that developers will be more careful without a QA "safety net" is a fallacy -- good developers are careful with or without QA, but I've never seen a developer who could find all their own bugs (and the ones they miss are often the worst).  And fobbing QA off on users is a great way to frustrate users and leave yourself open to competitors who have better quality.

I've written about this before, but I believe the main issue is that software QA (and product quality) remains under-appreciated, so in companies large and small it often suffers from under-investment.  The costs of poor quality are many:  failed product trials, low customer loyalty, increased customer support.  The best companies recognize that quality is one area where it almost always pays to invest.

Comments

[elexx-rd]

outdoor spot lights a voice for northern kentucky michelangelo articals why the straight guy goes down on the gay guy english language