Architecture Java Oriented Service | Info

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?

• Corinthian Column Architecture

• Architect County Landscape Marin

• Architectural Lunch And Learn

• Trellick Tower Architect

  LDNiCON. LDNiCON is about celebrating Londons architectural endevours and uncovering the quirky, sometimes seemingly bland, components of the ...

• Office For Metropolitan Architecture Oma

  architecture. To kick-start our exclusive film series 'Wallpaper* Visionaries', exploring ground-breaking ideas within the realms of architecture, film maker Victor ...