Test Plan Template

Release Information

Project:
Internal Release Number: 1.0
Related Documents:
LINKS TO RELEVANT STANDARDS
LINKS TO OTHER DOCUMENTS
Process impact: This document specifies "why" and "when" the testing will be done for this project. The "how" is described in the individual Test Cases that this Test Plan links to.

Introduction

Why is this Test Plan needed?
A Test Plan is needed to provide intelligent focus of limited project testing resources and expertise on the highest risk areas of the application and the "bread and butter" functionality of the system. A Test Plan is also needed to determine when the testing is done.
What Test lessons were learned in previous releases?
None yet. This is the first release.

Test Plan Synopsis

  1. Testing objectives and their rationale (risk, requirements, etc.)
    • ...
  2. Scope and Limitations
    • ...
  3. Testing strategy
    • Testing Strategy Chessboard

  4. Sources of business expertise for test planning, test case development, and tet execution
    • ...
  5. Sources of development expertise for test planning, test case development, and test execution
    • ...

Test Plans for XXX Phase

  1. Sources of test data for XXX Phase testing
    • ...
  2. XXX Phase test environments and their management
    • ...
  3. How can you tell when you are ready to start XXX Phase testing ?
    • ...
  4. How can you tell when you are finished XXX Phase testing ?
    • ...
  5. Testing schedule during Analysis
    • This schedule represents the master schedule of testing activity that the test team must manage.
    • This schedule is the composite of all test case documentation, execution, and reporting schedules for all development phases.
  • Each schedule entry represents one Test Case -> link to Test Case Suite
  • Each entry: test case id, name, status(w=written,as=attempted,successful,au=attempted,unsuccessful,c=corrected,crt=corrected, retested),status date,execution date
  • Test Case execution results analysis and reporting schedule
    • This schedule extends the test execution schedule to include time to analyze and report test results.
    • Usually, there is some analysis time and minimal report drafting time associated with each test execution so that the testers can begin to see the nature of the testing outcome early in the test execution schedule. Then if adjustments need to be made in the test execution to accommodate surprises, there is test execution schedule remaining for the tactical adjustments.
    • A first allotment of analysis and reporting time can range from a half day to a couple of days per test case.
    • A second allotment of time is made for analysis of results across multiple test case executions for more pervasive trends and completion of the drafted report. This second allotment of time can range from two to four weeks depending on the size and complexity of the testing project.
  • Test Case summary list (ID, title, brief description)
    • This list replaces test-suite in the ReadySET standard templates.
    • This is the summary list of test cases that you curently think are needed to adequately cover all the testing situations in this development phase.
    • Each Test Case ID in this table should ultimately point to a .html file of the same name.
    • This list is refined a number of times as more details about the application design become available.
    • Consider using a Test Case ID naming standard like [devel phase]-[test approach]-[sequence number]. This naming standard will cause the test case .html files to be sorted first by development phase, next by test approach (functional, structural, performance), and finally by sequence. That does allow sequence numbers to be reused across development phases.
  • XXX Module Testing Schedule

      Test Result Codes
  • SND = Successful, no defect correction required
  • UNS = Unsuccessful, awaiting defect correction
  • SAD = Successful after defect correction
  • Test Case ID: Title Date to Write : done? Date to Attempt : done? Test Result Code
    ... ... ... ...
    Test Case NN.0 ...... ...

    Test-Plan Checklist

    Have human resources been allocated to carry out the Test activities?
    Yes, human resources have been allocated. They are listed in the Resource Needs document.
    No, human resources have not been allocated. They are listed as "pending" in the Resource Needs document.
    Have machine and software resources been allocated as needed for the Test activities?
    Yes, the Test team will use desktop machines and servers that are configured like a "typical" business user.
    Yes, a Test Lab has been set up. The needed machine and software resources are listed in the Resource Needs document.
    No, needed machine and software resources are listed as pending in the Resource Needs document.
    Has this Test Plan been communicated to the development team, business expert team, and other stakeholders?
    Yes, everyone is aware of our prioritized quality goals for this release and understands how their work will help achieve those goals. Feedback is welcome.
    Yes, this document is being posted to the project website. Feedback is welcome.
    No, some developers or business experts are not aware of the testing goals, test activities, or testing schedules for this release. This is a risk that is noted in the Risk Management section of the Project Plan.
    Company Proprietary
    Copyright © 2003-2004 Jason Robbins. All rights reserved. License terms. Retain this copyright statement whenever this file is used as a template.
    Copyright © 2005 Jerry Everett, Ken Everett, and Ray McLeod. All rights reserved. License terms. Retain this copyright statement whenever this file is used as a template.