Introduction to Software Testing

The role of testing in software development has undergone radical changes in recent years. Testing has evolved from afterthought to a central activity in certain development methods—particularly agile methods. This chapter explains the evolving role of testing in software development and highlights the key theoretical and practical enablers for that evolution. The message of this chapter is as follows: If high-quality testing is not centrally and deeply embedded in your development process, your project is at high risk for failure. Your project might fail in the technical sense, in that you simply lose control of what the code actually does. Or it might fail in the business sense, in that your competitors roll out better functionality faster. It does not really matter which way you fail; sadly, the consequences are the same.

TAMING THE COST-OF-CHANGE CURVE

Traditional software engineering, as described in standard texts on software engineering, came into being as a field precisely because the development of large software projects was proving to be increasingly difficult—even impossible—using ad hoc development methods. Traditional software engineering focuses primarily on extensive modeling and upfront analysis. The goal is to reveal potential problems and changes as early as possible. The economic rationale is that effort spent on revealing failures early delivers an enormous return on investment. Every software engineering text shows the traditional “cost-of-change” curve, where the key variable is the lag between when a change should ideally be made and when the need for that change is recognized. Figure 1.1 in Chapter 1 illustrates this concept, by showing that the cost of finding and fixing faults balloons as we move from unit testing to integration testing to system testing to deployment.

A more general description is shown in Figure 4.1. The way to read this figure is to identify the time at which a decision (or the mistake) is originally made and the time at which that decision is revised (or mistake is repaired). The time interval between these events is shown on the horizontal axis. Cost, shown on the vertical axis, is a function of the length of time between the original and the revision. The “delta” cost starts at a small value for revisions made shortly after the original and climbs ever more steeply as the interval between the two events grows longer.