Identifying the requirements for test is the start of the test planning activity. The requirements for test identify what is being tested, and the scope and purpose of the test effort. Requirements for test are also used to determine the overall test effort (for scheduling, test design, and so on) and are used as the basis for test coverage.
Items that are to be identified as requirements for test must be verifiable. That is, they must have an observable, measurable outcome. A requirement that is not verifiable is not a requirement for test.
The following is performed to identify requirements for test:
The requirements for test may be identified from many sources, therefore it is important, that, as the first step, all the materials available for the application / system to be developed should be reviewed. The most common sources of requirements for test include existing requirement lists, use cases, use-case models, use-case realizations, supplemental specifications, design requirements, business cases, interviews with end-users, and review of existing systems.
Independent of the source of the requirement for test, there must be some form of identification that a requirement is going to be the target of a test. This results in the generation of a hierarchy of requirements for test. This hierarchy may be based upon an existing hierarchy, or newly generated. The hierarchy is a logical grouping of the requirements for test. Common methods include grouping the items by use-case, business case, type of test (functional, performance, etc.) or a combination of these.
The output of this step is a report (the hierarchy) identifying those requirements that will be the target of test.
See Guidelines: Test Plan for additional information on identifying requirements for tests.
To access risk, perform the following:
The test effort requires balancing resource constraints with risks. The most important requirements for test are those that reflect the highest risks.
Risk can be viewed from several perspectives:
Each requirement for test should be reviewed and a risk factor identified (such as high, medium, or low). Sometimes, assessing the risk with two or more of the risk perspectives may result in a different risk factor. In these situations, use the highest risk factor value. A statement regarding why a specific risk factor was selected for a given requirement for test should also be given.
Most applications have functions that are used often and others that are infrequently used. Therefore, to acceptably test an application, one must ensure not only are the highest risk requirements for test tested, but also those that are frequently used (as these often have the highest end-user visibility).
Identify an operational profile factor for each requirement for test and a statement justifying why a specific factor value was identified. This is accomplished by reviewing the business case(s) or by conducting interviews with end-users and their managers. Another method is to observe the end-users as they interact with the system or use software monitors / recorders to record end-user interaction with the system (for analysis).
Upon identifying and justifying the test risk and operational profile for each requirement for test, a test priority factor should be identified and justified. The test priority factor identifies the relative importance of the test requirement, and the order or sequence in which it will be tested.
The test priority factor is identified by using the risk factors, operational profiles, contractual obligations, other constraints, or a combination of all of these. It is important to consider all these factors when identifying the test priority to ensure that the testing is appropriate and focused.
See Guidelines: Test Plan for additional information on assessing risk and establishing test priorities.
The purpose of the test strategy is to communicate to everyone how you will approach the testing and what measures you will use to determine the completion and success of testing. The strategy does not have to be detailed, but it should give the reader an indication of how you will test.
Developing a test strategy includes:
The approach to test is a statement (or statements) describing how the testing will be implemented. This should state or refer to what will be tested, the major actions taken while testing, and how the results will be verified. The statements should provides enough information to the reader so they can understand what will be tested, although the depth of testing is not yet known, such as in the statements below:
The criteria for test are objective statements indicating the value(s) used to determine / identify when testing is complete, and the quality of the application-under-test. The test criteria may be a series of statements or a reference to another document (such as a process guide or test standards). Test criteria should identify:
Sample test criteria:
For each high priority use case:
In the above example, what is being tested is described by the statement "for each high priority use case." How the measurement is being made is described by the statement "all planned test cases and test procedures have been executed." The criteria used for evaluation is included in the last two statements "all identified defects have been addressed" and "all planned test cases and test procedures have been re-executed and no new defects identified."
Any special considerations for testing or dependencies should be listed, such as those shown below:
See Guidelines: Test Plan for additional information on developing test strategies.
Once it's been identified what's being tested and how, there is the need to identify who will do the testing and what is needed to support the test activities. Identifying resource requirements includes determining what resources are needed, including the following:
For most test efforts, you'll need resources who can do the following:
Test environment (includes hardware and software)
Two different physical environments are recommended (although it is not necessary):
Software will also be necessary for testing. The minimum software needed are the application-under-test, the client O/S, the network, and the server O/S. Additionally software maybe necessary to accurately simulate / duplicate the production environment, this software might include:
It should be stated what software tools (for testing) will be used, by whom, and what information or benefit will be gained by the use of each tool.
Software testing relies heavily upon the use of data as input (creating or supporting a test condition) and as output (to be compared to an expected result). Strategies should be identified for the following test data related issues:
Creating a schedule includes:
The following assumptions should be considered when estimating the test effort:
Test estimation should also consider partitioning the effort differently
within each phase of the testing lifecycle as the weight (of effort) for some
types of vary during the lifecycle. For example, the test effort for performance
testing, the test execution activity carries a major share of the work estimate,
due to the effort to set up the test system and execute tests in a complex
A test project schedule can be built from the work estimates and resource
assignments. In the iterative development environment, a separate test project
schedule is needed for each iteration. All test activities are repeated in every
To generate a test plan, perform the following:
Prior to generating the test plan, a review of all the existing project information should be done to ensure the test plan contains the most current and accurate information. If necessary, test related information (requirements for test, test strategies, resources, etc.) should be revised to reflect any changes.
The purpose of the test deliverables section is to identify and define how the test artifacts will be created, maintained, and made available to others. These artifacts include:
The last step in the Plan Test activity is to generate the test plan. This is accomplished by assembling all the test information gathered and generated into a single report.
The test plan should be distributed to at least the following: