For small simple testing projects, a single, short test plan may be all that is needed to sufficiently convey the intended activities of the testing team to other interested parties. However, for larger projects, where the work may be divided across several teams working at separate locations for different managers and at different points in the system's development, it may be easier to create several focused test plans rather than one large all- encompassing plan. For example, one plan may focus on testing the physical security of the computer facilities that the Web site will be housed in, another may describe the penetration testing that will be performed by an outsourced security-testing firm, and a third may concentrate on the unit-level tests that the Web application development team is expected to do.
If multiple test plans will be used, the activities within each plan need to be coordinated. For instance, it does not make sense for all of the test plans to schedule the creation of a common test environment; instead, the first plan that will need this capability should include this information. The higher the number of test plans, the easier it is to manage each individual plan, but the harder it becomes to coordinate all of these distributed activities, especially if the organization's culture does not lend itself to nonhierarchical lines of organizational communication.
One solution to the problem of multiple test plan coordination that many practitioners choose to utilize is the master test plan (MTP). The MTP is a test plan that provides a high- level summary of all the other test plans, thereby coordinating and documenting how the entire security-testing effort has been divided up into smaller, more manageable units of work (as depicted in Figure 2.4).
Figure 2.4: MTP.
A by-product of defining multiple test plans is that such an approach may facilitate several security-testing teams working in parallel, which provides a significant advantage when working in Web time. Additionally, having several documented and well-scoped groups of tests makes outsourcing some or all of the testing effort much more controllable.
As is the case with each individual test plan, it is often the process of developing an MTP rather than the actual end product that is of greater help to the testing team. Creating the MTP should facilitate discussions on what testing objectives should be assigned to each individual test plan as part of an overall scheme, rather than relying on the recognizance of head-down individuals working in isolation on separate test plans. Craig et al. (2002) and Gerrard (2002) provide additional information on the concept of a master test plan.
Summary
Whether a person chooses to use a test plan format based on an industry standard, an internal template, or a unique layout customized for this specific project, the test plan and its associated documents should be reviewed to make sure that it adequately addresses the test-planning considerations summarized in Table 2.7.
Table 2.7: Test-Planning Consideration Checklist YES NO DESCRIPTION
□ □ Have the system's security requirements been clarified and unambiguously documented?
Table 2.7: Test-Planning Consideration Checklist YES NO DESCRIPTION
□ □ Has the goal (and therefore scope) of the testing effort been clearly defined?
□ □ Have all the items (and their versions) that need to be tested been identified?
□ □ Have any significant items that will not be tested been listed?
□ □ Has a change control process for the project been defined and have all the individuals who will approve changes to the scope of the testing been identified?
□ □ Have all the features that need to be tested been identified? □ □ Have any significant features that will not be tested been listed? □ □ Has the testing approach (strategy) been documented?
□ □ Have the criteria (if any) by which the system will be deemed to have passed security testing been documented?
□ □ Have the criteria (if any) for halting (and resuming) the testing effort been documented?
□ □ Have the deliverables that the testing effort is expected to produce been documented?
□ □ Have all the environmental needs of the testing effort been researched and documented?
□ □ Has a configuration management strategy for the items that are to be tested been documented?
□ □ Has a configuration management strategy for the test scripts and test data (testware) been documented?
□ Have responsibilities for all the testing activities been assigned?
□ □ Have responsibilities for all the activities that the testing effort is dependent upon been assigned?
□ □ Have staffing needs been identified and resourced? □ □ Have any training needs been identified and resourced? □ □ Has a test schedule been created?
Table 2.7: Test-Planning Consideration Checklist YES NO DESCRIPTION
documented?
□ □ Have any unusual acronyms and terms been defined?
□ □ Have any supporting documents been identified and cross- referenced?
□ □ Have those individuals responsible for approving the test plans been identified?
□ □ Have those individuals responsible for accepting the results of the testing effort been identified?
□ □ Have those individuals who need to be kept informed of the testing effort's plans been identified?