This chapter is from the book
This chapter is from the book
This chapter is from the book
What is Rapid Testing?
We use the term "rapid testing" in this book as a complement to the notion of "rapid development." As Steve McConnell has pointed out, rapid development means different things to different people. To some people, it's rapid prototyping. To others, it's a combination of CASE tools, intensive user involvement, and tight time boxes. Rather than identify rapid development with a specific tool or method, McConnell (1996, p. 2) makes the following definition:
Rapid development is a generic term that means the same thing as "speedy development" or "shorter schedules." It means developing software faster than you do now. A "rapid development project," then, is any project that needs to emphasize development speed.
In a similar vein, rapid testing means testing software faster than you do now, while maintaining or improving your standards of quality. Unfortunately, there is no simple way to achieve rapid testing. Figure 1.1 shows a somewhat simplistic sketch that represents rapid testing as a structure that is built on a foundation of four components. If any of these components is weak, the effectiveness of testing will be greatly impaired. As illustrated in the figure, the four components that must be optimized for rapid testing are people, integrated test process, static testing, and dynamic testing. We'll briefly examine each of the four components.
){kind=link}
Figure 1.1 Essential components of rapid testing.
People
As every test manager knows, the right people are an essential ingredient to rapid testing. There are several studies that show productivity differences of 10:1 or more in software developers. The same is true with test engineers—not everyone has the skills, experience, or temperament to be a good test engineer. Rapid testing particularly needs people who are disciplined, flexible, who can handle the pressure of an aggressive schedule, and who are able to be productive contributors through the early phases of the development life cycle. While the main focus of this book is on test process and technique, some ideas about the "people side" of testing will be included in Chapter 6.
Integrated Test Process
No matter how good your people may be, if they do not have a systematic, disciplined process for testing, they will not operate at maximum efficiency. The test process needs to be based on sound, fundamental principles, and must be well integrated with the overall software development process. We will spend a good portion of Part I of this book describing ways to improve the test process, with a more detailed discussion of practical techniques and implementation tips presented in Part II. The focus of our discussion will be to explore ways of better integrating the development and test activities.
Static Testing
In the previous section we defined static testing as test activities associated with analyzing the products of software development. Static testing is done for the purpose of validating that a work product such as a design specification properly implements all the system requirements, and verifying the quality of the design. Static testing is one of the most effective means of catching bugs at an early stage of development, thereby saving substantial time and cost to the development. It involves inspections, walkthroughs, and peer reviews of designs, code, and other work products, as well as static analysis to uncover defects in syntax, data structure, and other code components. Static testing is basically anything that can be done to uncover defects without running the code. In the experience of the authors, it is an often-neglected tool. Static testing will be discussed throughout Parts I and II of this book.
Dynamic Testing
Often when engineers think of testing, they are thinking of dynamic testing, which involves operating the system with the purpose of finding bugs. Whereas static testing does not involve running the software, dynamic testing does. Generally speaking, dynamic testing consists of running a program and comparing its actual behavior to what is expected. If the actual behavior differs from the expected behavior, a defect has been found. As we'll see in later chapters, dynamic testing will be used to perform a variety of types of tests such as functional tests, performance tests, and stress tests. Dynamic testing lies at the heart of the software testing process, and if the planning, design, development, and execution of dynamic tests are not performed well, the testing process will be very inefficient. Dynamic testing is not only performed by the test team; it should be a part of the development team's unit and integration testing as well.