Understanding Quality Cost

As we know, building quality into the software involves cost – I came across a detailed and useful article on “Quality Cost” at LogiGear Newsletter.

Author Rob Pirozzi classifies quality costs into four types: Prevention costs, Appraisal costs, Internal failure costs, and External failure costs. For software practitioners and quality professionals, it is very important to know these four categories of quality cost and decide where to invest most of the efforts to see that the other costs are balanced.

Rob also describes the activities that we typically do for each of these quality cost types. According to Rob,

Prevention costs represent everything a company spends to prevent software errors, documentation errors, and other product-related errors.

Appraisal costs include the money spent on the actual testing activity. Any and all activities associated with searching for errors in the software and associated product materials falls into this category.

Internal failure costs are the costs of coping with errors discovered during development and testing.

External failure costs are the costs of coping with errors discovered after the product is released.

Thanks Rob for a detailed article and analysis done.

There is always one more bug

Michael Bolton at DevelopSense blog says that a significant question for software testers is:

“Is there a problem here?”

Great question for testers. In a thought exchange, one of our clients said “I am a firm believer in the fact that however long we test, there-is-always-one-more-bug. As a testers, it is very crucial for us to know where to draw a line. Obviously, when we complete a test cycle, there should be no show stopper but there-is-always-one-more-bug lurking somewhere in the application. It is the same “there-is-always-one-more-bug” theory that pushes a tester to think differently, to think beyond what an analyst or designer thought and challenge the system.”

We believe that combining the quest of finding a bug (”Is there a problem here?”) with “there-is-always-one-more-bug theory” can work wonders for software testers in coming out with findings no one in the project team would have ever thought of.  We believe it is these findings that differentiate great testers from average ones.

Load Testing – Considerations

Load Testing is one of the most difficult phases of development cycle – since it deals not only with the testing tools but also with the overall test infrastructure.

I suggest reading “The Ten Commandments of Load Testing” over at “My Load Test” weblog listing some of the very basic considerations on load testing.

The ones I particularly liked are:

Thou shalt have testable requirements. - Requirements specific to load testing is one of the most common pitfalls where a tester does not have any idea about the clients expectations. It helps to gather the client requirements and note them down so that they can be tested against.

Thou shalt test for the worst case. - Load Tests are generally planned for the average scenarios and not for peak ones. E.g A travel booking site may have 20 concurrent users on an average day and 100 concurrent users during vacations.

Thou shalt monitor your test environment infrastructure. – Load Testing should always be done after the application has stabilized and it should be done from a live environment. There could be many implications as far as deployment environment, hardware etc. are concerned and these factors should be carefully thought of.

Read the full post here for more details.