Intro Models Documentation Design Scripting Tools Execution Defects Reporting  

The Documents Required for Testing

When testing begins

As its name implies Waterfall development is all about sequential flow. The flow is normally conception, specification, design, code and test. A common theme on Waterfall projects is the availability of documentation, for testers the specifications are the ultimate authority. Usually the waterfall testing process begins toward the end of specification, at this time there are usually draft requirements available and the test design process can begin. Usually the test lead or manager sows the seeds for the rest of the team by writing the documentation that will define how testing is to be performed. Depending on how formal the testing process is one or more of the following documents will be generated:

Test Strategy

The Test Strategy is a high level document, it does not give directions or specify in detail how individual tests should be conducted it is more a statement on how testing will be approached across the project. It will define:

  • The scope of testing, what is tested and what isn't
  • The roles of testers and the people they interface with
  • Requirements Tracibility Matrix
  • Types of testing to be conducted e.g. functional, performance, regression
  • Risks and how they are mitigated
  • Reports and metrics
  • The testing environment
  • Testing tools that will be required including the test repository to be used
  • Defect reporting including the definition of defect severity and priority
  • Test entrance and exit criteria

The Test Strategy is aimed at all project members including project managers, developers and designers. It should communicate and clarify how the project is to be tested. It is usually the first test document to be issued and once agreed and approved is unlikely to change.

Test Plan

The Test Plan is a more detailed testing document and is written later in the project lifecycle. In smaller projects the test stratgey and plan are often combined but in larger more complex projects there will be at least one test plan that follows the approach defined in the Test Strategy. Test Plans will specify the scope of testing to a more detailed level and be specific about the testing environments used and the testers involved. Typical contents are:

  • Test Schedule
  • Test estimations
  • Software features under test
  • Requirements Traceability Matrix
  • Scripting Standards
  • Test Environments
  • Test identifiers used
  • Escalation procedures
  • Defect process flows
  • Success or Fail criteria
  • Test evidence collection

Test Plans are more of a living document and it is likely that they will change during the development lifecycle. It is important that the test team are engaged in its production and follow it throughout the testing phase. Once test plans are issued and requirements are known work can begin on test design.


Home      |      Testing      |      Telecoms      |      Resources      |      Clients      |      Contact     |     Care Database
 Copyright © 2016 Chic Computer Consultants. All rights reserved