...
- Project plan
- Product plan
- Related test plans
- Requirements specifications
- High level design document
- Detailed design document
- Development and testing standards
- Methodology guidelines and examples
- Organisational standards and guidelines
- Source code, documentation, user guides, implementation records
Glossary
Terms and acronyms used in the document, target domain, and testing as needed are described here. The glossary facilitates communication and helps in eliminating confusion.
Introduction
This is the executive summary part of the plan which summarizes its purpose, level, scope, effort, costs, timing, relation to other activities and deadlines, expected effects and collateral benefits or drawbacks. This section should be brief and to the point.
...
Any special requirements or constrains of the testing in terms of the testing process, environment, features or components need to be noted. They may include a special hardware, supporting software, test data to be provided, or restrictions in use of the system during the testing.
Testing can be organized as periodic or continuous until all pass criteria are met, with passing of identified issues to the development team. This requires defining the approach to modification of test items, in terms of regression testing.
...
Issues noticed during testing are often consequence of other previously noticed defects, so continuation of testing after certain is number of identified defects in the affected functionality or item is wasting of resources, particularly if it is obvious that the system or the item cannot satisfy the pass criteria.
Test Deliverables
This section describes what is produced by the testing process. These deliverables my be the subject of quality assessment before their final approval or acceptance, and besides all the elements of test documentation that are described here, may also include test data used during testing, test scripts, code for execution of tests in testing frameworks and outputs from test tools.
Testing Activities
This section details testing activities and tasks, along with their dependencies and estimates of duration and the resource required.
Test Environment or Test Bed is an execution environment configured for testing. It may consist of specific hardware, OS, network topology, configuration of the product under test, other application or system software, test tools, etc. The Test Plan for a project should enumerated the test beds(s) to be used.
Staffing and Training Needs
This is the specification of the people and skills needed to deliver the plan. It should also describe trainings on the tested system, elements of the test environment and test tools that need to be conducted.
Responsibilities
This section specifies personal responsibilities for approvals, processes, activities and deliverables described by the plan. It may also detail detail responsibilities in development and modification of the elements of the test plan.
Schedule
The schedule of phases should be detailed to the level which ensures certainty that is attainable with information available at the moment of planning. It should define the timing of individual testing phases, milestones, activities and deliverables and be based on realistic and validated estimates, particularly as the testing is often interweaved with development. Testing is the most likely victim of slippage in other activities, so it is a good idea to tie all test dates directly to the completion dates of their related developments.
This section may also describe the approach for dealing with specific slippages, which may include simplification or reduction of some non-crucial activities, relaxation of the scope or coverage, elimination of some test cases, engagement of additional resources, extension of testing duration.
Risks and Contingencies
This defines all other risk events, their likelihood, impact and counter measures to overcome them. Same the risks may be testing related manifestations of the overall project risks.
The risks may include the lack or loss of personnel at the beginning or during testing, unavailability or late delivery of required hardware, software, data or tools, delays in training, or changes to the original requirements or designs.
They can be described using the usual format of the risk register, with attributes such as:
Category
Risk name
Responsible (tracker)
Associated phase/process/activity
Likelihood (low/medium/high)
Impact (low/medium/high)
Mitigation strategy (avoid/reduce/accept/share or transfer)
Response action
Actionee
Response time
Although some contingency events may actually be opportunities, it is, due to the limited scope of testing within the wider project or service delivery context, quite unlikely that the opportunities related to the very testing process will occur. However, the outcome of testing or some of its results may offer opportunities related to the subject of testing that may be enhanced, exploited or shared.
Test Status Report
Test Completion Report
...
Test Environment Requirements
Test Environment or Test Bed is an execution environment configured for testing. It may consist of specific hardware, OS, network topology, configuration of the product under test, other application or system software, test tools, etc. The Test Plan for a project should enumerated the test beds(s) to be used.
Test Environment Report
Detailed test results
...