Test Strategies and Plans

Member Submitted

configuration, don't forget the system software as well.

Data. Again, it is necessary to identify where the data will come from to populate the test database. Choices might include production data, purchased data, user-supplied data, generated data, and simulators. It will also be necessary to determine how to validate the data—it is false to assume that even production data is totally accurate. We must also access the fragility of the data (so we know how often to update it!).

Interfaces. My students no doubt get tired of hearing me say "interfaces are risky"; but indeed they are. When planning the test environment, it is very important to determine and define all interfaces. Occasionally the systems that we must interface with already exist; in other instances, they may not yet be ready and all we have to work with is a design spec or some type of protocol. If the interface is not already in existence, building a realistic simulator may be part of our testing job.

Facilities, Publications, Security Access, etc . This may seem trivial, but we must insure that we have somewhere to test, appropriate security clearance, and so forth.

15.0 Staffing and Training Needs
The actual number of staff required is of course dependent on the scope of the project, schedule etc. What we want to do in this section is describe the number of people required and what skills they need. You may merely want to say that you need fifteen journeymen testers and five apprentice testers. Often, however, you will have to be more specific. It is certainly acceptable to state that you need a special person: "We must have Jane Smith to help establish a realistic test environment."

Examples of training needs might include learning about: how to use a tool, testing methodologies, interfacing systems, management systems such as defect tracking, configuration management, basic business knowledge (related to the system under test), etc.

16. Responsibilities
I like to include a matrix in this section that quickly shows major responsibilities such as establishment of the test environment, configuration management, unit testing and so forth. I believe that it is best to specify the responsible parties by name or by organization.

17. Schedule
The schedule should be built around the milestones contained in the Project Plan such as delivery dates of various documents and modules, availability of resources, and interfaces. Then it will be necessary to add all of the testing milestones. These testing milestones will differ in level of detail dependent upon the level of the test plan being created. In a Master Test Plan, milestones will be built around major events such as requirements and design reviews, code delivery, completion of users manuals, and availability of interfaces. In a Unit Test Plan, most of the milestones will be based on the completion of various Programming Specs and Units

Initially it may be necessary to build a generic schedule without calendar dates; this will identify the time required for various tasks and dependencies without specifying particular start and finish dates. Normally the schedule will be portrayed graphically using a Gant chart to show dependencies.

It is beyond the scope of this article to discuss estimating in any great detail. But if we are ever going to gain credibility in the software development arena, we must get better at estimating time and resources. It is important that the schedule reflect how the estimates for the milestones were determined. For example, when the time schedule is very aggressive, estimating becomes even more critical—so that the planning risks and contingencies and test priorities can be specified.

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