ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel
  • »
  • Technology»
  • Computers & Software»
  • Computer Science & Programming

Software Test Plan

Updated on June 19, 2010

IEEE 829 describes a set of software test documentation. For test plans it describes a document containing the following sections:

  1. Test Plan Identifier.
    Specify a string that uniquely identifies the test plan within the organisation.
  2. Introduction.
    Summarise the items and features to be tested. References other relevant documents, e.g. project test plans, QA plans, applicable standards.
  3. Test items.
    Identify the items to be tested. Include the software version numbers and reference any relevant documents, e.g. requirements specification, design specification, user’s guide, installation guide.
  4. Features to be tested.
    Identify any features of the test items that will be tested.
  5. Features not to be tested.
    Identify any features of the test items that will not be tested. Identify any combination of features that will not be tested. Indicate why a feature is not being tested, e.g. feature not yet available or feature considered to be stable.
  6. Approach.
    Give an overall description of the approach taken to test the items. Such as the techniques and tools used. Indicate any significant constraints that influence the approach taken. Give an indication of the staff and environmental resources that are required.
  7. Item pass/fail criteria.
    Specify the criteria used to decide whether each item under test has passed or failed. For example: the percentage of tests passed or the number of outstanding faults.
  8. Suspension/resumption requirements.
    Give reasons why the testing activity could be suspended such as appropriate hardware being unavailable or an item under test having faults that make it unusable.
  9. Test deliverables.
    List the products of the testing activities, e.g. test plan, test case specifications, test reports and logs.
  10. Testing tasks.
    Identify the tasks required in order to prepare and perform the tests, e.g. write the test-case specifications, prepare test data, prepare the test tools and maintenance of the test environment.
  11. Environmental needs.
    Specify the test environment. Identify the required hardware, system software, network links and test tools. Identify any new software stubs and drivers that may be required.
  12. Responsibilities.
    Indicate which person or group is responsible for each aspect of the plan, such as: designing tests, performing tests, organising the environment and organising training.
  13. Staffing and training needs.
    Specify the number of testers required and indicate the skills they should have. Specify what training is required, both in the system under test and any test tools.
  14. Schedule.
    Estimate the times required to perform each testing task. Identify scheduling dependencies within the tasks. Identify any previously published milestones that constrain the testing process. Schedule the testing tasks based on this data.
  15. Risks and contingencies.
    Identify the risks associated with the plan such as lack of resources or significant problems with the test items.

    Specify contingency plans to address the identified risks such as the hiring of additional testers or increasing working hours.
  16. Approvals.
    Identify who can approve this plan and other documentation generated by it. Identify who can approve the testing as complete.


    0 of 8192 characters used
    Post Comment

    • profile image

      agiletester 6 years ago

      this is overkill for agile, imho.