Making Software Better

Understanding Quality Cost

gatewaylabs — Thu, 05 Feb 2009 09:46:13 +0000

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

gatewaylabs — Thu, 05 Feb 2009 09:45:11 +0000

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

gatewaylabs — Tue, 27 Jan 2009 10:43:53 +0000

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.

Testing as an information service

gatewaylabs — Mon, 22 Dec 2008 07:36:16 +0000

Testing can control quality, but cannot assure it. Quality Assurance, as we know, is much more than just applying tests on the projects – its about choosing, customizing and applying a methodology that is best suited to the project considering the project scope, complexity, technical risks and many other parameters involved. When we do QA, we think processes.

We associate testing with quality control – but when we do testing, are we really empowered to “control” the quality? After we report bugs, is it in our control to get them fixed? My experience states that the answer is “No”. Even when we do testing, we are not really controlling the quality – we are just reporting the state of application. This belief of mine found a strong support when I read similar views by Elisabeth Hendrickson who thinks of testing as an information service. Here is the snippet from her post Questions and Answers -

” My new insight was the classic: Testing can tell us about the absence of quality, but cannot ensure it. I still think that’s true, but that insight doesn’t guide what or how I should test. It fails to inspire me. It’s accurate, but not helpful.

My next realization was that Testing is an information service. Testers provide information that decision makers can use to mitigate risk and make better decisions about software projects. This insight explains why testers should not be the gatekeepers. We provide information, not judgment. We identify and explain risks. We act as advisors. We don’t make the news, we report it. And we shouldn’t ever accept the role of quality police.”

She hits the point when she states,

I now see testing as an information service that answers questions for project stakeholders. Or, bumper-sticker style: Project stakeholders have questions; testers have answers.

Excellent!