QA

Software professionals learn a lot from technical presentations and articles. But sometimes a well-told story can illustrate technical concepts even better, in an entertaining and memorable way. This week, Lee Copeland tells why it's good to be a software bard, teaching your audiences hard concepts in a decidedly nontechnical way.

In a number of manufacturing industries, the quality function has become an integral part of the business. The software quality movement has not had nearly that level of success, but the pressure is building to do so. The obstacle is cost—particularly the cost of delivering that improved software quality. Since the beginnings of our industry, we have emulated the quality movement in hardware manufacturing; unfortunately, that path will not lead us to the success they found. Software development and hardware manufacturing are different. Our goal is the same but the path to success is different. To achieve the success we seek, we must set our own path and expand the testing objective from "test to fail" to "test for knowledge."

Software is often seen as different from other products that seem more tangible and less flexible. In this article, Gerold Keefer points out that the perception of flexibility is not always a positive perception, and approaching software as a product that should be "done right the first time" can improve quality. Gerold also illustrates a number of tangible-product metaphors common in the software industry.

It makes sense that people who are always correct will have the power to influence others. But testers who base their authority on correctness might be in for a rough time. Bret Pettichord explains in this week's column why it's a good idea to show concern as well as correctness.