The Wall Street Journal made this observation about the winner-take-all society: "Today, it’s axiomatic in Silicon Valley that the Internet is a ‘land grab’ where the dominant early player walks off with most of the booty." There’s even a book by James Fallows, entitled Faster: The Acceleration of Just About Everything.

In the words of Ian Diery, former head of marketing for Apple Computer, "Being first is more important than being best." (This works well as a strategy…until the competitors catch up with the company’s innovations, and the customers aren’t so willing to compromise quality anymore.)

Put another way, the claim is that good quality delivered late is useless. As Napoleon Bonaparte said to a messenger in 1803, "Go, sir, gallop, and don't forget that the world was created in six days. You can ask me for anything you like, except time."

Does Fast Delivery Have to Compromise Quality?
There isn’t an iron-clad tradeoff between time to market and quality: these two factors do not have to be mutually exclusive. There are many situations where improved practices have decreased time to market, and have increased the quality of the delivered system at the same time.

As one example, IBM reported that, in one of their divisions (the Santa Theresa Lab), over a two-year period the software testing efforts decreased by 43 percent on average, and elapsed time to deliver products to market decreased by more than 15 percent, when software professionals and their managers adopted more effective techniques for defect prevention, quality assurance, and testing.

The quality of the IBM division’s systems improved at the same time, with the numbers of bugs remaining in the delivered systems dropping by approximately 50 percent.

Conversely, in many situations, longer delivery times have led to poorer quality. As the system delivery date becomes late and then more late, the temptations increase to "cut corners" on defect prevention measures, testing, and fixes.

As reported by Capers Jones, IBM found that the software products that have the fewest defects also have the shortest delivery cycles. In a study of 4,000 projects cited by Jones, poor quality was one of the most common causes of project overruns. The reason is the delay caused by reworking to remove defects.

In response to customer demands and competitive pressures, most organizations are continually attempting to reduce their product development cycles and system delivery times. Organizations including Hewlett-Packard and AT&T have reported that their system development and delivery cycles have steadily been reduced over the last decade, in part by making the test and QA processes more effective.

The (Apparent) Quality vs. Speed Contradiction
In a speed-focused environment, you are likely to hear the following arguments against testing:

Testing is the bottleneck in delivering systems. This statement is akin to saying that checking that each car runs is the bottleneck in the automobile manufacturing process. Testing requires tradeoffs of time, resources, and results, like any activity. But when the critical element is time, test teams can make decisions and take actions to avoid protracted testing. Even better, defect prevention practices such as walkthroughs and effective unit testing can deliver cleaner software and keep the time for testing and re-work to a reasonable amount.

We don't have time for those quality measures; we are in a rush. But the race does not always go to the swift. The landscape is littered with the carcasses of firms that delivered systems to market quickly, but with so many problems that they alienated their customers and lost anyway. The software field contains many forgotten names of vendors and products that once glittered with promise. The fact that they were first to market has long since become irrelevant.

This article is entitled "Speeding the Software Delivery Process," but it could be called "Speeding the Testing Process." The testing and quality assurance activities on a project have a rich potential for streamlining and improvement, and so are worth our attention.

So, How Do We Speed Delivery?
There is no silver bullet or quick two-minute answer to the question "How can we improve time to market without sacrificing quality?" There isn’t one simple, magical thing we can do to speed delivery. Rather, we need to pay careful attention to several factors. Success comes from managing seemingly minor items which all can impact time to market.

A common approach to speeding the testing is simply to exhort the testers to "work smarter and harder" and to cut the scheduled test time, but this approach usually undermines the effectiveness of the test. "Damn the torpedoes, full speed ahead," is a great rallying cry—until you hit a torpedo.

Can we use the test and QA processes to speed not just the testing but also the overall product delivery cycle? Yes, definitely. There are many ways to reduce the test cycle time and speed the overall delivery process, including

1. managing testing like a "real" project

2. strengthening the test resources

3. improving system testability

4. getting off to a quick start

5. streamlining the testing process

6. anticipating and managing the risks

7. actively and aggressively managing the process

For the remainder of this article, I will elaborate on points 1 and 2 in the above list. Subsequent articles in this three-article series will discuss the remaining points 3–7.

1. Manage Testing like a "Real" Project

This suggestion may seem obvious, but the lack of sound project management is a common cause of delays and mediocre (or worse) quality.

Have a workable test plan. Taking the time to develop a plan that is more than a sketch on a napkin is a radical idea in some organizations. But without an organized plan, you can fall into testing blindly and reactively.

• Educate yourself early and as thoroughly as possible on the system functionality, the users’ success factors, the likely risks and vulnerabilities, and the test environment and testing tools.
• Understand the "pull/push" nature of test projects. If support activities, like developing test procedures or test tool training, are not done during the first third of a project, in the hurly-burly of pushing toward the project deadline they never will be done.
• Enhance your estimating and negotiating skills. Estimating realistically is difficult, but can be done—it is an acquired skill to be vigorously pursued.
• Remember to identify and allow for contingencies.
• Incorporate mechanisms in the test plan, to monitor progress vs. plan and update the test plan periodically as conditions change.

Develop realistic estimates. Without estimates and schedules that can be relied on, we are already out of control. But most test team leaders and testers are not confident of their skills in this area.

Understand and control the factors that can lead to project slippage. For example, an apparently simple, last-minute change to a feature can play havoc with the testing schedule.

Manage the critical path. When any task on the critical path slips, the entire test project slips. This requires, of course, that we know what the critical path is (and it can change frequently, as events change).

Coordinate closely with other groups. Most vendor software and Web-based development projects today utilize so-called RAD (rapid application development) methods such as XP (extreme programming) and agile methods. To be effective, RAD requires a more fine-tuned coordination of testers with others, such as developers, Web site content managers, users, and marketers in a vendor organization, than is needed with traditional system development methodologies.

Manage the interdependencies among activities. More than mere coordination is needed on most projects—the interactions among the co-dependent parties must be proactively planned and managed. Development and testing projects usually have many mutual dependencies among their internal tasks, and more-difficult-to-manage dependencies with tasks external to the project. We may even have gridlock: person A may be dependent and waiting on person B, who is waiting on person C, who in turn awaits some deliverable from person A.

Managing the interdependencies means that we first know what they are, and have up-to-date information on the status of predecessor tasks. The test and QA milestones should be included in the overall system development project schedule, and coordinated with the other project activities (design, programming, etc.).

Balance the test resources to the workload demands. Plan ahead: maintain a forward-looking calendar of the major systems and new versions planned for the next eight to sixteen weeks, and their likely demands on the testing resources. Schedule and allocate test and QA resources for these development projects, especially to provide early preventive QA.

Use project management tools. Realistically, test planning, scheduling, monitoring, and updating test project plans cannot be done without a good project management tool, such as Microsoft Project. These tools facilitate more sophisticated modeling and exploration of alternative courses of action, by allowing rapid iterations of planning scenarios and by using "what if?" sensitivity analysis.

However, the majority—perhaps 85 percent—of test professionals do not use project management tools. They use informal devices like paper lists of tasks instead (the "back of the envelope"), and manage by the seats of their pants.

Manage expectations. Sometimes the test function is blamed for late delivery, because the testing occurs at the end of the delivery cycle; therefore, it is conspicuous as the reason why the system is not yet ready. People will say, "It takes too long to test!" Educate managers and clients by presenting status information on when a system was actually ready to test, how many defects have been found during the test, and what effort is required for an adequate test.

2. Strengthen the Test Resources

Add test resources. Many test efforts today are under-resourced, partly because of optimism, denial, and lack of understanding of what is needed to perform an adequate test. Many managers and professionals are surprised by the amount of testing indicated by time-proven test estimating formulae, and frankly do not believe them. However, we have considerable evidence that these rules of thumb are about right, from actual projects in leading software organizations. Many software vendors, for example, have a ratio of software engineers to testers of 3:1 or 2:1.

Resist the temptation to add people resources to a late project. Despite the suggestion above to add resources, Brook's law states that adding people to a late project only makes it later. If the newly added resources join the test effort too late, or the newcomers are not experienced and already oriented to the project, Brook's law will be obeyed.

In variations of the application of Brook’s law, avoid bringing in new testing tools or changing test processes beyond the first third of the testing project. The learning curve and dislocation caused by the changes are too risky in the last two-thirds of the project. (Fred Brooks is a professor at the University of North Carolina who led the software development team for IBM’s breakthrough IBM/360 computer in the 1960s.)

Ensure the right person is allocated to each work activity (i.e., the best person available for that particular activity). Testing is a very broad field with many specialized types of expertise and context-specific knowledge. A particular task that takes one team member five days may take another team member only two hours.

Give the testers the facilities they need. It is not a good sign when testers are waiting for shared testers’ equipment, which currently is tied up with other demands. Or when testers are struggling and wasting time with quirky, difficult, or obsolete tools. Or when testers do not have the support personnel they need, such as network administrators to troubleshoot the network, or database administrators to extract and download test databases.

Upgrade the skills and experience levels of the test team. In some organizations, juniors are used in testing to free the valuable people for "the important activities." While they may be bright and motivated, neophytes can require an exceedingly long time to get up the learning curve or, worse, they may perform an inadequate test and not even know it. At the very least, the test team should be seeded with a few highly competent, battle-scarred veterans to guide the juniors.

Expertise is needed in three key areas: the functionality or subject matter, the technological foundation for the system, and effective test techniques.

Increase the involvement of the clients and end users in the test process. These people bring functional subject matter expertise, a fresh perspective, and additional hands to the test effort. Involving them early in the test process also builds psychological ownership of the system and narrows the gap between user expectations and the reality of what the system can actually do.

Next
Part 2: "Conduct Early and Streamlined Testing"
Part 3: "Manage the Risks and the Process"