Documentation Hierarchy

In order to identify and create the required tests, execute them and manage the process, we need to produce a detailed set of test plans. These plans vary in strategic aim, use, level of detail, and content.

During the planning stage the documentation set required to be produced are:

• Test Policy [one-off company wide document].
• Test Strategy [a high level one-off document].
• Project Test Plan [one for each project].
• Phase Test Plan [one for each phase if required.

Test Policy Document

• A document describing the organisation's philosophy towards software testing
• Normally a short high-level document . Reflects the company's business, products, marketplace, customers, business risks, mission statements etc.

Test Policy statements will reflect the nature of the business, the risks associated with the products and market place, and the business attitude regarding the required quality of products and deliverables. The test policy will dictate the overall approach to testing and the strategies employed.

Example Test Policy Statements

• A company manufacturing circuit boards for the space shuttle might include policy statements like:
• The build and test processes will be automated and amalgamated wherever possible
• All individual components will be tested for accuracy of tolerance prior to insertion into a build

Test Strategy Document

• A high level document defining the test phases to be performed and the testing within those phases for a programme(one or more projects)
• Details the overall approach to testing
• Meets the policy requirements
• Integrates the test function with other areas at the strategic level.

The test strategy details the overall testing approach and what will be done in order to satisfy the criteria detailed in the test policy. This document is a strategic document and as such it must complement the other IT strategic working practices and development procedures. Testing is a part of the development process and must be fully integrated with the other project teams in order to be successful. Test strategies cannot be developed in isolation, they must have buy in from the other project areas and work in conjunction with the other teams - remember testing cannot do it alone!

The test strategy will detail:

• Test approach (V-model)
• Test team structure (independent, role based)
• Ownership and responsibilities
• Test tools strategy
• Reporting process
• Fault and change management process etc.

Some examples of the type of information you may see in a strategy for a company designing WEB sites may look like this:

"In order to meet the company's test policy on quality deliverables within tight timescales the company has adopted the extreme programming lightweight development methodology."

The independent test function will provide the XP coach to the development teams for each project.

All project baseline documentation and code will be subject to appropriate review and sign off.

The independent test function will specify, create and execute the acceptance test cases in conjunction with the customer.
Automated test tools will be considered at the start of [and throughout] each project and will be used wherever advantage can be identified.