Test Planning and the software Test Plan are key tools in the arsenal of a Test Manager and should be used widely across software testing. They help set the rules of the game and also guide the teams in the right direction in any test endeavor and are the basics of software testing.
Test planning applies for each test level and also includes the methods for monitoring for each. This Is the activity of establishing or updating a test plan which starts at the initiation of the test process and in line with the Test Strategy.
Contents
Software Test Plan
The Software Test Plan is a document describing the scope, approach, resources and schedule of intended test activities. As a record of the test planning process, it also covers:
- test items
- features to be tested
- testing tasks
- who will do each task
- degree of tester independence
- test environment
- test design techniques
- Entry and Exit Criteria (with their rationale)
- risk assessment based on requirements
- contingency planning based on risk assessment
- integration of reactive test techniques in execution
During test planning, the Test Manager role is to defines the approach for each software testing level:
- What is tested
- Goals & Objectives
- Test techniques & tools
Effective test plan in software testing
In order to have an effective planning, we need to consider the complex relationships between test phases, but also between development and test. Some examples would be:
- the requirement trace ability matrix
- informal transfer of information.
In other words, the requirement trace ability matrix is a document that maps and traces user requirement with test cases. The main purpose of Requirement Trace ability Matrix is to see that all test cases are covered so that no functionality should miss while doing Software testing.
Another factor for effective planning would be the proper listing of the testing scope with each feature associated with a design specification, environment, etc. This should relate to each test level. A good example would be the uat test plan.
Contact with all stakeholders has to be initiated at this stage, but also all external dependencies identified and service level agreements put in place.
In order to properly measure the progress, evaluate the Entry and Exit criteria and to exercise control, we need to put in place software test metrics starting with software Test Planning.
Other software testing documents
Software testing involves the creation of a number of other test documents and work products and most of these are produced by Test Analysts and Technical Test Analysts: defect reports, test case specifications, and test logs.
The Test Manager should ensure consistency and quality of these work products through the following activities:
- Establishing and monitoring metrics for the quality of these work products (percentage of rejected defect reports, etc.)
- Working with the Test Analysts and Technical Test Analysts to:
- select and customize appropriate templates for the work products
- establish standards for these work products (degree of detail necessary in tests, logs, and reports)
- Reviewing testing work products using the appropriate techniques and by the appropriate participants and stakeholders
Software testing also involves the creation of test results reports, which are typically produced by the Test Manager and are described later in these software testing materials. The extent, type, and specificity of test docs can be influenced by:
- the chosen software development life cycle
- applicable standards and regulations
- the product quality
- project risks associated with the particular system being developed
There are various sources of templates for testing work products such as IEEE 829 [IEEE829] designed for use in any industry and that contain a high level of detail that may or may not be applicable to a particular organization. It is a best practice to tailor the IEEE 829 documents to create standard templates for use in a particular organization. The consistent application of the templates reduces training requirements and helps to unify processes across an organization.
Example – When and what to use:
Example – Test Design
Example – Test Case
Example – Test Item
Example – Test Log
Example – Test Incident Report
Example – Test Summary report
This article is based on the ISTQB Advanced Syllabus version 2012 and it also references the ISTQB Foundation Syllabus version 2018. It uses terminology definitions from the ISTQB Glossary version 3.2.
