How to Write a Software Development Testing Plan: Quality Software Testing Starts with a Master Test Plan

The delivery of quality software is more often than not the result of meticulous test planning. A solid Master Test Plan acts as a route-map for all software testing to be undertaken for a project and details which phases of testing will be included at the various stages of development. The Master Test Plan should reflect the overall Testing Strategy which has been drawn up for the testing function and should be written by the Test Manager for the project it pertains to.

What Should a Master Test Plan Include?

The Master Test Plan should reflect the structured testing methodology, policies and processes which have been laid down in the overall Testing Strategy Document. The plan will outline how the project team aims to approach the testing required, in order to excercise the software solution thoroughly and minimise risk to the business; it will discuss how this testing is to be conducted and the environment in which the testing is to be run. The plan should include the following areas:

  • Introduction – briefly what the document is, who it is intended for and how it should be used.
  • Location of the document, owner and sign off – where the document is stored on the company network, the owner of the document, a list of resources for review and sign off and a list of resources for distribution only.
  • Background to the project – briefly what the project is and how it has come about. You should also include a list of documents which have fed into the Master Test Plan here such as test strategy, business requirements, project initiation documentation etc.
  • Any diagrams from the project showing the systems architecture – this can usually be derived from documentation produced earlier on in the project lifecycle such as technical designs or functional specifications. Diagrams are particularly useful for the Master Test Plan as they can be used to clearly illustrate factors of integration, third party vendor considerations and areas which are in and out of scope. Include some wording to accompany the diagram and draw specific attention to these factors.
  • What testing is to be undertaken – there should be an overview of all the testing phases to be undertaken and the deliverables from each. (See the specific sections on these below).
  • Third party vendor testing – if part of the solution is being delivered by a third party, outline it here together with details of the controls which are going to be in place to assure the quality of code delivered by the third party.
  • Test environments – this outlines the number of test environments and what testing will be conducted in which environment. For instance unit testing is likely to be conducted in the development environment. Note also any environment constraints, for example if the Functional Test phase and the User Acceptance Test phase share the same environment and these phases overlap, this can cause data sharing issues which can hamper the verification of each team’s test results.
  • Roles and responsibilities – who is responsible for each phase?
  • Timeline – a plan of when each phase is due to be conducted and any contingency built in.
  • Defect reporting process/tools – this section details any defect tracking tools that the project will use, who will control these, the reporting mechanisms in place plus details of any daily meetings to discuss defects. This will also include any service level agreements which are in place for turnaround of defects from development to test.
  • Test tools/automated testing – details of any test management or automation tools such as Quality Centre, QTP, Selenium, LoadRunner and which phases these will be used within.
  • Implementation details pertaining to testing – this reflects on the considerations around implementation; for example, what is the “back-out” protocol and how is this to be tested? Is software due to be implemented on different platforms at different times and what testing needs to be undertaken to ensure that no existing live functions are affected by this during the cut-over period?
  • Constraints/risks and issues – this section should detail any constraints and risks to the project such as limitations of the test environment, lack of test resource etc. Also include a link to a testing issues log which should be maintained throughout the project. This will be used to track ongoing issues and the resolutions which are agreed as the project progresses.
  • Waiver process – this should detail the procedure which must be followed should it be decided that a test phase is being omitted. If this is already documented within the test strategy then a link to this document can be provided. Also note here why it has been decided to omit any test phases which are not required.
  • Management reporting – details of the metrics to be provided throughout the testing phases (and at the end of testing) to measure the quality of the code/readiness of the solution for delivery.

What Should be Included in the Test Phase Sections of the Master Test Plan?

This section of the test plan will document the key features of each phase and why this particular area of testing is being undertaken. Note that each test phase will have its own test plan which will outlay what needs to happen in that phase in low level detail. At Master Test Plan level, details of the phase should be limited to an overview as follows:

  • What the phase is about – key objectives of the phase.
  • What is the entry criteria for each phase? (E.g. no high priority issues outstanding from unit testing before starting functional testing).
  • What is the process for each phase? (Refer to the test strategy document where this should be fully detailed).
  • What are the deliverables for each phase? (See the section below – “Deliverables from each Test Phase” for detail of what should be included here.)
  • Who is responsible for managing, delivering and signing off each test phase?

Deliverables from each Test Phase

In your Master Test Plan you will need to detail at a high level the deliverables which you expect to see from each test phase. Deliverables may differ between test phases depending on the nature of a project however, here is an example of what might be included.

  • Phase level test plan
  • Test scenarios and scripts
  • Identification of test data
  • Test metrics
  • Defects
  • End of Test Report
  • Checklists for each phase
  • What is the exit criteria for each phase?
  • What is the sign-off/handover process for each phase?

Note that whilst the Master Test Plan should list these deliverables, the detailed phase test plan should outline how each deliverable will be produced together with roles, responsibilities, timelines, issues, risks, constraints and reporting mechanisms.

How to Manage the Master Test Plan – Sign Off, Walkthrough and Version Control

Once the test plan has been completed it should be signed off by all interested parties including each of the lifecycle development managers as well as the test leads for each of the test phases documented. If there are any third party vendors involved in the project, they should also sign off the test plan to state that they agree to the process via which their software quality will be monitored and controlled. The environments manager should also be involved in sign off to ensure that the test environment requirements documented within the plan can be met.

A useful way of communicating the plan is to have all interested parties read through the initial draft and then hold a formal review/walkthrough meeting. This way, verbal agreement can be ascertained prior to formal sign off and any issues can be voiced, discussed and clarified before subsequently being documented in the signed off version.

The Master Test Plan may be written at the inception of a project and in this case it is likely that testing requirements will change as the proposed software solution begins to take shape. As this happens, later versions of the Master Test Plans should be issued after amendment and agreement with all affected parties.

Comments are closed.