Speed-optimized Software QA; or Cancer

QA is QA, right? Either you’re committed to quality or you’re not. If you are, you use the widely accepted tools and techniques and produce a high-quality product, or you accept the fact that you’ll churn out crap. What else is there to say?

Here’s what: if you accept this view and apply it in the usual software development environment, your QA processes metastasize, invade all parts of the process, and cause endless pain and suffering – not to mention crap software. Eliminating the cancer can only be done by leaving the cancer-causing environment. That means finally saying good-by to peace-time software and going to war.

Software Quality Assurance

Software QA is a BIG subject. There are lots of methods within a broad set of accepted practices. Experts assure us that “quality” goes way beyond testing; it infiltrates every aspect of the software SDLC.

But testing by itself, which is just part of quality, is a HUGE subject. You can get certified. Here are some of subjects involved in testing according a leading certification organization.

Here’s what’s involved just in test planning:

The SQA cancer

Most organizations aren’t aware of it, but the typical, expectations-based, peace-time software development organization is highly prone to QA and testing cancer.

Everybody is supposed to do good work. You’re supposed to take the flawless results of the previous group’s work, do what you do to it, and pass it on to the next group – error-free.

When it’s obvious you’ve been given crap, it’s easy to reject what you’ve been given and throw it back at the slugs who gave the crap to you. But all too often, the problems don’t emerge until you’re pretty far down the line of doing your own work. Then it’s upsetting and embarrassing. The schedule is at risk, and who’s at fault?

Once this happens a couple times, on the sending and receiving ends, most people respond by creating as many quality measure as they can, to be applied to the work they’re given. Then, having been blamed for producing bad work a couple times, they run all sorts of tests on the work they’ve produced before passing it on.
Why wouldn’t you? You don’t want to receive bad work, and you certainly don’t want to be blamed for giving bad work to someone else. But you can see how the QA/testing steps are reproducing.

Inside coding itself, it can be even worse. In addition to inspecting the code that's calling them and that they're calling, the programmers can "enhance" their code with additional code whose sole purpose it to check whether the inputs they're given -- at run-time -- are correct, and then again to test the outputs they're about to give.
As though that isn't enough, lots of quality-minded programmers are way into writing code that tests each individual piece of code; this can be before you write the code (i.e., test-driven development, which is currently fashionable, something programmers say they want to do to show everyone else how good they are) or after you write the code (i.e., plain old unit testing).

What's worse is, I've just skimmed the surface!

There is no escape

You think that's bad? Try to do something about it. Whenever anything goes wrong, you're likely to hear one of the following:

• I wasn't allowed to buy adequate test tools
• We weren't adequately trained on the tools
• I didn't have enough time to get enough coverage
• Lots of old tests had bugs, I had to disable them to meet the deadline
• We changed so much old code, I didn't have time to update all the tests for it.
  
• My regression testing has poor coverage, I need more time/money
• We have too much emphasis on testing -- quality is something we need to build in

Then you'll find a group that isn't testing inputs or outputs. More time and money needed.

Get mad and remove any of these steps? You've just given the group a "get out of jail free" card if/when something goes wrong.

Cancer-free testing and quality

Testing cancer is one of the main reasons why peacetime software is a lengthy, organized expensive process ... that produces disastrous results. Then, when you try to fix the problem so it doesn't happen next time -- the cancer spreads. Current quality and testing methods are a cancer on software development, and there is only one known cure.

The cure is simple. It's documented. It's proven in practice, at many places over many years. But it's radical, and requires a shift to wartime software thinking. It requires shifting to global process optimization, and optimizing for speed. It takes less time and produces far superior results. Here are some of the key points:

• Forget "quality," whatever that is. Concentrate on testing.
• Move from correctness-based testing everywhere to change-based testing at just a couple key points.
• Move all testing from the lab to production.
• Move all testing from periodic to continuous.

There are a number of posts in this blog that spell this out. There are even books! The advance of software QA cancer is inexorable and unstoppable in environments that are friendly to it. There is only one cure: Wartime software and its associated methods.