Software Test Plan
IEEE 829 describes a set of software test documentation. For test plans it describes a document containing the following sections:
- Test Plan Identifier.
Specify a string that uniquely identifies the test plan within the organisation.
Summarise the items and features to be tested. References other relevant documents, e.g. project test plans, QA plans, applicable standards.
- Test items.
Identify the items to be tested. Include the software version numbers and reference any relevant documents, e.g. requirements specification, design specification, user’s guide, installation guide.
- Features to be tested.
Identify any features of the test items that will be tested.
- Features not to be tested.
Identify any features of the test items that will not be tested. Identify any combination of features that will not be tested. Indicate why a feature is not being tested, e.g. feature not yet available or feature considered to be stable.
Give an overall description of the approach taken to test the items. Such as the techniques and tools used. Indicate any significant constraints that influence the approach taken. Give an indication of the staff and environmental resources that are required.
- Item pass/fail criteria.
Specify the criteria used to decide whether each item under test has passed or failed. For example: the percentage of tests passed or the number of outstanding faults.
- Suspension/resumption requirements.
Give reasons why the testing activity could be suspended such as appropriate hardware being unavailable or an item under test having faults that make it unusable.
- Test deliverables.
List the products of the testing activities, e.g. test plan, test case specifications, test reports and logs.
- Testing tasks.
Identify the tasks required in order to prepare and perform the tests, e.g. write the test-case specifications, prepare test data, prepare the test tools and maintenance of the test environment.
- Environmental needs.
Specify the test environment. Identify the required hardware, system software, network links and test tools. Identify any new software stubs and drivers that may be required.
Indicate which person or group is responsible for each aspect of the plan, such as: designing tests, performing tests, organising the environment and organising training.
- Staffing and training needs.
Specify the number of testers required and indicate the skills they should have. Specify what training is required, both in the system under test and any test tools.
Estimate the times required to perform each testing task. Identify scheduling dependencies within the tasks. Identify any previously published milestones that constrain the testing process. Schedule the testing tasks based on this data.
- Risks and contingencies.
Identify the risks associated with the plan such as lack of resources or significant problems with the test items.
Specify contingency plans to address the identified risks such as the hiring of additional testers or increasing working hours.
Identify who can approve this plan and other documentation generated by it. Identify who can approve the testing as complete.
More by this Author
Statement testing is a whitebox, dynamic testing technique. It requires examination of the source code and the creation of tests that will exercise individual statements. The project plan should indicate the proportion...
Branch testing and decision testing are closely related. We will treat them same. When 100% coverage is concerned, the two techniques are the same. Branch and decision testing require examination of the source code...
Introduction These notes describe how to go about modulo 2 addition, subtraction and division. Modulo 2 Arithmetic Modulo 2 arithmetic is performed digit by digit on binary numbers. Each digit is considered...