Pervasive testing means getting the right people working together through the right processes at the right time for high-ROI testing. Pervasive testing is the final piece of the test investment puzzle, and just as important as all the others. Through pervasive testing, all the ideas we've explored so far come together.
Does your organization thrust the responsibility for testing on a small cadre of people, secluded in a dimly-lit test lab, right at the end of the project? Even with the best tools and techniques, such a team can't create the kind of return on investment I've been telling you about throughout this series of articles. Successful test efforts start early, involve all appropriate stakeholders and participants, and come about through cross-functional teamwork. Like the roots of a potted houseplant spreading through soil, successful test efforts pervade the project.
Pervasive Testing Timelines
When testing pervades a project, the test tasks start on the first day of the project. Test team members are involved in project planning and requirements definition. In parallel with these activities, testers organize a quality risks analysis for all key stakeholders, as discussed earlier in this series. Based on the decisions made in that analysis of what features and functions of the system require the most testing, the test manager prepares an estimate and a plan for the test effort. Once the plan and estimate are approved, testers proceed to configure the test environment and create the test cases, data, and tools at the same time that programmers are creating the system.
A graphical view of what a time-pervasive test effort looks like is shown in Figure 1. The test task bars are black, while the other project-related task bars are gray. During planning and system development, a parallel test task exists. These test tasks often focus on project documents. For example, quality risk analysis focuses on the requirements specification. At the same time as they use such documents to plan and build their tests, testers also identify potential problems, saving the project team time and money through early defect detection and removal. Early versions of the test cases and data are available to the programmers during development. Component testing, primarily structural, starts early in the project, as soon as the first components are coded, providing even more opportunities for early—and cheap—bug detection and removal. As communicating pairs of components complete component testing, integration testing begins. Once integration testing is done, we are ready to start system testing. In this way, bugs are found as early as possible, when it's cheapest to fix them. Lowering the cost of internal failure improves the return on the testing investment even more than reducing the cost of external failure discussed in the first article.
Pervasive Testing Participants
This kind of pervasive testing can only happen when all the right people pitch in. Senior management and executives, of course, must make the commitment to start testing early. As testers armed with the knowledge that early testing is a smart investment, we can convince them of the benefits.
During quality risk analysis, all the right people must get involved. Sales and marketing people in the mass-market world, and business analysts and users in the IT world, must help define and prioritize the quality risks. Customer support or help desk staff must be involved, too.
Some test execution work will fall to developers, such as structural component and integration testing. (For a case study of what happens when developers abdicate their testing role, see Elisabeth Hendrickson's article, "More Testing Worse Quality," on her Web site, www.qualitytree.com.) Independent test teams generally focus