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.
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.
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.