Creating software is a notoriously error-prone activity. If the errors might have serious consequences, we must check the product in some systematic way. Every project uses testing: check the code by executing it. Some projects also inspect code, or use static analysis tools to check code without executing it. Finding the best balance among these assurance methods, and the best techniques and tools for each, is an active area of research and controversy. Each approach has its own strengths and weaknesses.

The unique strength of testing arises because it actually executes the code in an environment similar to where it will be used, so it checks all of the assumptions that the developers made about the operating environment and the development tools.

But testing is always incomplete, so we have to use other assurance methods also. And there are other important development products besides code. To be sure that the code solves the right problem, we must have a specification that describes what we want the program to do. To be sure that the units of code will work together, we need a design that describes how the program is built up from parts and how the parts communicate. If the specification or design turns out to be wrong, code may have to be reworked or discarded, so many projects conduct reviews or inspections where people examine specifications and designs. These are usually expressed in informal notations such as natural language and hand-drawn diagrams that cannot be analyzed automatically, so reviews and inspections are time-consuming, subjective, and fallible.