Test Strategies and Plans

[article]
Member Submitted

Recording schedules based on estimates also provides the test manager with an audit trail of how the estimates did and did not come to pass, and forms the basis for better estimating in the future.

18. Planning Risks and Contingencies
Many organizations have made a big show of announcing their commitment to quality. We’ve had quality circles, quality management, total quality management, and who knows what else. Unfortunately, in the software world many of these same organizations have demonstrated that their only true commitment is to the schedule.

Most of us have taken part in projects where the schedule is at best ambitious and at worst impossible. Once an implementation date is set, it is often considered sacred. Customers may have been promised a product on a certain date; management credibility is on the line; corporate reputation is at stake; or our competitors may be breathing down our neck. At the same time, as an organization we may have stretched our resources to the limit. It is not my purpose to address the many reasons why we so often find ourselves in this unenviable spot. Rather I would like to talk about what we can do about it. 

  1. XAlter the schedule—which marketing says can't be done...
  2. Reduce the scope—but we promised our customers...
  3. Reduce the quality (this usually means reducing testing or allowing more defects in the final product)—but our last release failed!
  4. Add resources (including overtime)—but there are none to add and everyone is already working around the clock...
  5. Punt...

Unfortunately all of the above choices seem bad—and all too often Management decides that they are all unacceptable. If Management does not make proactive decisions in situations like this, the technical staff will often end up making the choices by default. Initially more resources will be added, typically in the form of overtime. If this does not solve the problem, the team will begin to take shortcuts—eliminating a document here, a review there, or eliminating an entire set of tests. Not surprisingly, the quality suffers.

If the project is still in jeopardy, functionality that is not absolutely essential will be rescheduled for a later release, or the date may be slipped. Eventually, then, the new target date may be met, and a watered-down system of poor quality is delivered to the customer late by a very frustrated development team. Sound familiar?

The purpose of this section is to help us make intelligent, informed decisions. Almost every project team can identify the planning risks that worry them: late requirements, test environment problems, late delivery of software, etc. Our goal is to decide in advance what to do if one of these planning risks comes true. Our choices were outlined above: reduce the scope, delay implementation, add resources, or reduce quality processes.

If the choice is made to reduce quality processes (such as testing) it becomes critical that we know what testing to reduce. This plan helped to identify the software risks (see Section 6) and these risks should have helped us to focus and prioritize our testing to reduce them. Naturally, we don't want to learn at the last moment that we have to reduce testing...and then learn that it is the critical components of the system that have not yet been tested! I also mentioned that we can use risk to prioritize "Features to Be Tested (See Section 7)" and to help decide what will go into the section “Features Not to be Tested (See section 8)." It should be apparent at this point that Planning Risks, Software Risks, Features to Be Tested, Features Not to Be Tested, and

About the author

Rick Craig's picture Rick Craig

Rick Craig is a consultant, lecturer, author, and test manager, who has led numerous teams of testers on both large and small projects. In his twenty-five years of consulting worldwide, Rick has advised and supported a diverse group of organizations on many testing and test management issues. From large insurance providers and telecommunications companies to smaller software services companies, he has mentored senior software managers and helped test teams improve their effectiveness. Rick is co-author of Systematic Software Testing and a frequent speaker at testing conferences, including every STAR conference since its inception. 

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01