This part of a test plan is designed to describe at a high level how you intend to perform a test on a software product. This description is not a detailed specification of all test procedures that are planned to be used. The approach which description is included in the test plan should be based on certain considerations. This section of the document may contain the following topics:
- Project documentation and static testing of requirements.
- Static testing and dynamic testing which should be carried out at stages of unit testing and integration testing.
- Property testing.
- Load testing / stress testing / performance testing.
- Security testing.
- Installation testing / upgrade testing.
- Duplication testing / recovery testing.
- Graphical user interface testing.
- Regression testing.
- Acceptance tests: alpha, beta and other types of on-site testing.
- Conformance testing of results of defect tracking.
- Automated and manual interruption testing.
- Types of testing which are conducted by outside organizations.
- The use of defect tracking system to enter error messages.
If only some part of a long-term strategy is implemented, for example, automation of the test process and test cases, you can determine which specific aspects of the corresponding long-term plan will be implemented in the current test project, and refer to the document describing the automation strategy. For instance, it is likely that some tool is intended to be used, or an attempt is made to automate testing the GUI for the first time. In addition, it may be planned to use the services of offshore test organizations in order to test the product under load and under overload conditions. This section is a suitable place to describe the plan at the conceptual level and provide references to any written agreements that have been concluded with third-party organizations. Quality control companies have been helping lots of businesses all over the globe to build the higher quality and safer software apps that appeal to the target public.
When testing incremental versions of a software product, the approach to testing each version is likely to be the same. You should be able to save time by borrowing large fragments of the same section of the test plan drawn up for previous versions, but at the same time carefully analyze the consequences of any changes made to the current version of the product.