Software Quality Testing: The Cost of Quality is the Cost of Bugs !
The first graphic projected on the overhead screen in a QA Class shows a rising curved line representing the cost of finding a bug as the project proceeds. That is, bugs caught during the requirements phase are much less costly than bugs caught during the design phase, the ones identified during the design phase cost less than those caught during coding, and bugs caught during coding cost less than bugs identified during test. The big no-no is to let bugs get caught after delivery. The cost of these bugs is huge, and many a creative graphic artist has depicted this fact by making the bugs larger in the later phases of development.
I have a problem with this graphic. I think it is original intent was to dramatize the necessity of front-loading the development effort, i.e., not skimping when it comes to doing requirements analysis or program design. The problem is that this graphic is now used to downplay the importance of system testing and the subject matter expertise needed to do it right.
How many times have you heard a QA person say that you can not test quality into a product, it has to be built in.
To better understand the bug-cost graphic I look at these bugs in the following way - the small bug depicted in the requirements phase represents the cost of finding a requirements bug in this phase, the larger bug shown in the design phase is the cost of this same requirements bug if found during the design phase, and the largest bug of them all looming above the delivery phase is the cost of this same requirements bug if found during this later phase.
If you look at the graph in this way the value of bugs found in the final testing phase take on a different quality. Instead of seeing these bugs as monstrosities that should have been caught earlier in the development cycle, they become normal sized bugs that are not so scary. This new way of looking at the chart might even make finding bugs in this phase seem as natural as finding those little bugs during the requirements phase.
I hope my point is coming across - testing during the final stages of development is just as important as creating a solid requirements or design document. As a matter of fact, common sense tells you that testing is one of the most useful tools to ensure a quality product. Why do you think they make doctors and lawyers pass tests before getting their license to practice? And why do you think professors test their students several times during the semester, and base their final grade on the outcome of these tests? I think it is because we all know that the test motivates people to do their best. The end result is a doctor we can trust and, when applied to the software engineering discipline, a program we can rely on.
I have a problem with this graphic. I think it is original intent was to dramatize the necessity of front-loading the development effort, i.e., not skimping when it comes to doing requirements analysis or program design. The problem is that this graphic is now used to downplay the importance of system testing and the subject matter expertise needed to do it right.
How many times have you heard a QA person say that you can not test quality into a product, it has to be built in.
To better understand the bug-cost graphic I look at these bugs in the following way - the small bug depicted in the requirements phase represents the cost of finding a requirements bug in this phase, the larger bug shown in the design phase is the cost of this same requirements bug if found during the design phase, and the largest bug of them all looming above the delivery phase is the cost of this same requirements bug if found during this later phase.
If you look at the graph in this way the value of bugs found in the final testing phase take on a different quality. Instead of seeing these bugs as monstrosities that should have been caught earlier in the development cycle, they become normal sized bugs that are not so scary. This new way of looking at the chart might even make finding bugs in this phase seem as natural as finding those little bugs during the requirements phase.
I hope my point is coming across - testing during the final stages of development is just as important as creating a solid requirements or design document. As a matter of fact, common sense tells you that testing is one of the most useful tools to ensure a quality product. Why do you think they make doctors and lawyers pass tests before getting their license to practice? And why do you think professors test their students several times during the semester, and base their final grade on the outcome of these tests? I think it is because we all know that the test motivates people to do their best. The end result is a doctor we can trust and, when applied to the software engineering discipline, a program we can rely on.
0 comments:
Post a Comment