Click Here to Accept Poorly Tested, Low-Quality Software

Computerworld - Poor-quality software can hurt your business. You are under tremendous pressure to do more with less in all aspects of your business. The selection of the software products that will be the backbone of your infrastructure is now, more than ever, a make-or-break decision for both you and your company.

And, guess what, your software providers are under the same pressure to do more with less, and that pressure can and does affect the quality of the products that run your business. The reality is that the pressure to get software out the door very often trumps the due diligence of testing and quality assurance (QA) that most software companies wish they could perform. No one wants to deliver poor-quality software. Acquisition and retention of customers, positive press and investors require the delivery of high-quality products for a software company to remain strong and competitive.

So why does delivery of poor quality software still occur?

The answer can be summed up in one word: history. Historically, software users have learned to expect, accept and put up with inferior quality. Also, in the historic "traditional" software development model, engineering teams use a serial development process in which each step in the process hinges on the completion of the previous step (requirements definition, design, coding, testing and production). The bulk of this work happens within the development or engineering teams' domain -- the QA teams become involved well after the majority of the software development life cycle has occurred. As a result, the quality is often slapped on instead of being built-in, and the message is: features and time-to-market come first, and only then comes quality.

On top of that, the QA team often physically sits outside of development organizationally, and again historically, QA managers have considerably less power and influence than development managers. So you've got different reporting structures and differing priorities across the teams that produce the software product, with testing and quality usually coming in last in more ways than one.

Despite the risks and potential costs, most software buyers today implicitly accept this lackadaisical approach to quality. Would you ever buy a new car that required you to sign a contract never to hold the maker liable for any damage or harm even if they were negligent? Clearly not, but you do it almost every time you buy software. It's still very common that the maker of the software is only liable for the cost of the CD on which the software is delivered. And you know those