Why do we test?

The question has come up here at work on a few occasions: "Why do we test?" The idea being that when a tester finds a bug, it could get prioritized down below the "fix" line, and the product would still ship with this as a known defect. That being the case, they (the testers) sometimes express frustration, and wonder why they even take the time to find bugs if we are going to ship product with them. Good testers have a strong desire to ship a perfect product.

The problem, of course, is that every defect has to be balanced against the list of fixed defects and enhancements that have already been added to the product. With an iterative process in place, the product is " shippable" on a regular basis, but it is never perfect. There comes a point of diminishing returns, where the latest development version of the product is so much better than the current customer version, that we simply need to get the development version into customers hands. As long as we are not introducing new defects, and as long as the new enhancements function to a minimal level of acceptance and quality, then the product can go out the door.

So, why do we test? The answer is: "To mitigate risk." We need to understand what the current status of the product is, and what our risks are with releasing it, before we can even consider getting it into customers hands. We need to ensure ourselves that we are not introducing any new defects, or at least any new significant defects, in our attempt to get new features to our customers. Testing plays an extremely important role in this Risk Mitigation decision making process.

Of course, the other key part that testing plays is in the "test first" methodology. The testing department should know how a feature is going to work before the developer ever starts writing a line of code. In this culture, testing ensures that the features are implemented in the way that best meets customer needs and goals, rather than simply ensuring that it works the way the developer intended it to work. If the test case is written first, with input from the Customer Representative, then testings goal is to ensure that the new feature meets customer goals. No small feat, given the myriad of software in the world today that really doesn't meet anyone's need but the developer who wrote it.