One of the fashion statement associated with testing these days is "testers should focus on preventing bugs rather than finding them". This is a very tricky idea and is full of traps for testers. Recently a post came up in software testing yahoo group that somehow got into this topic of preventing bugs.
Coming from the context driven school of testing and trained by likes of James Bach, Cem Kaner, Michael Bolton and others - I was skeptical about testers preventing bugs. Fundamental idea of our school of testing has been that as testers we bring to the light the information about bugs and risks in the software we test. Then we report it in a way to stakeholders (powers to be) to act on it.
Many testers fall into trap and take upon themselves (may be due to role/corporate hierarchy pressure) to task of preventing bugs. After all - who does not like someone who prevents bugs than someone who simply reports. Borrowing from manufacturing industry - many business leaders in IT and IT enabled business - firmly believe in prevention is better than cure. Who can resist the nobleness of preventing or saving "nine" by stitching in time.
Let us consider following two cases -
Testers prevent bugs in the requirements by asking question about ambiguity in requirements. Requirement bugs might not be counted as bugs by many - they might be termed as unclear requirements. Calling out what is not clear in requirements is one of valuable contribution of testers.
When Pairing with developers - testers prevent bugs as and when bugs are occur. For example tester may shout .. "hey you are missing exception handling code for that exception or hey you got if loop condition incorrect". That is closest you can get in preventing bugs.
In an email conversation with Michael says -
"we do not use a binary model “pass or fail”. People who do that are setting themselves up for bad testing. A product—any product—can “pass” a test but still have terrible problems. A product can “fail” a test, yet there’s no problem. (For instance: the square root of 2 is 1.4142136, right? Well, it isn’t; the square root of two is not a rational number; it never ends, and certainly lot at the seventh decimal place. But for many—even most—circumstances, 1.4142136 is good enough; just fine; not a problem."
This has been a great learning -- testers throw light on ambiguity - that does not mean they prevent bugs happening. Similarly, in pair testing - testers spot the bug in shortest time possible but they did not present it from happening... that is "early bug detection".
Thanks James and Michael - lesson re-affirmed.
Coming from the context driven school of testing and trained by likes of James Bach, Cem Kaner, Michael Bolton and others - I was skeptical about testers preventing bugs. Fundamental idea of our school of testing has been that as testers we bring to the light the information about bugs and risks in the software we test. Then we report it in a way to stakeholders (powers to be) to act on it.
Many testers fall into trap and take upon themselves (may be due to role/corporate hierarchy pressure) to task of preventing bugs. After all - who does not like someone who prevents bugs than someone who simply reports. Borrowing from manufacturing industry - many business leaders in IT and IT enabled business - firmly believe in prevention is better than cure. Who can resist the nobleness of preventing or saving "nine" by stitching in time.
Let us consider following two cases -
Testers prevent bugs in the requirements by asking question about ambiguity in requirements. Requirement bugs might not be counted as bugs by many - they might be termed as unclear requirements. Calling out what is not clear in requirements is one of valuable contribution of testers.
When Pairing with developers - testers prevent bugs as and when bugs are occur. For example tester may shout .. "hey you are missing exception handling code for that exception or hey you got if loop condition incorrect". That is closest you can get in preventing bugs.
In an email conversation with Michael says -
"we do not use a binary model “pass or fail”. People who do that are setting themselves up for bad testing. A product—any product—can “pass” a test but still have terrible problems. A product can “fail” a test, yet there’s no problem. (For instance: the square root of 2 is 1.4142136, right? Well, it isn’t; the square root of two is not a rational number; it never ends, and certainly lot at the seventh decimal place. But for many—even most—circumstances, 1.4142136 is good enough; just fine; not a problem."
This has been a great learning -- testers throw light on ambiguity - that does not mean they prevent bugs happening. Similarly, in pair testing - testers spot the bug in shortest time possible but they did not present it from happening... that is "early bug detection".
Thanks James and Michael - lesson re-affirmed.
