Test Artifacts. Test Plan

According to the processes or software development methodologies, a certain number of test artifacts (documents, models, etc.) are created and used during the testing.

The most common test artifacts are:

  • The Test Plan is a document describing the entire scope of testing, beginning with the description of the object, strategy, timetable, criteria for starting and ending testing, up to the necessary equipment, special knowledge, and risk assessment with options for their resolution.
  • The Case & Test suite test is a sequence of actions by which you can check whether the function under test meets the requirements.
  • Bug Reports / Defects are documents describing a situation or a sequence of actions that led to an incorrect operation of the test object, indicating the causes and expected result.

Today we will study the test plan. The following articles will be devoted to the other two points.

Test Plan

The Test Plan is a document describing the whole amount of testing work, starting with the description of the object, strategy, timetable, criteria for starting and ending testing, up to the necessary equipment, special knowledge, as well as risk assessment with options for their resolution.

Recommendations on writing the Test Plan

Each methodology or process tries to impose its own formats for processing test plans. We offer you, as an example, test plan templates from RUP (Rational Unified Process) and IEEE 829:

  1. Test Plan Template RUP
  2. Test Plan Template IEEE 829

Looking closer, it becomes clear that both documents describe the same thing, but in different forms. In the event that the standard template does not suit you, or you decide to come up with your own document format that is more suitable for you, then from experience we can say that a good test plan should at least describe the following:

  1. What should I test?
    • description of the testing object: systems, applications, equipment
  2. What will you test?
    • list of functions and description of the system under test and its components separately
  3. How will you test?
    • the testing strategy, namely: the types of testing and their application in relation to the testing object
  4. When will you test?
    • The sequence of works: Preparation (Test Preparation), Testing (Testing), Analysis of results (Test Result Analisys) in the context of the planned development phases
  5. Criteria for starting testing:
    • readiness of the test platform (test stand)
  6. Completeness of the development of the required functional
    • availability of all necessary documentation
  1. Criteria for completing the test:
    • the results of testing meet the criteria of product quality:
  • the requirements to the number of open bugs are satisfied
  • the exposure of a certain period without changing the source code of the application Code Freeze (CF)
  • the exposure of a certain period without opening new bugs Zero Bug Bounce (ZBB)

Having answered in your test plan for the above issues, you can assume that you already have a good draft of a document for planning testing. Further, to make the document more or less serious, we propose to add it with the following items:

  • Environment of the system under test (description of firmware)
  • The equipment and software needed for testing (test stand and its configuration, programs for automated testing, etc.)
  • Risks and ways to resolve them

Types of test plans

Most often in practice, you have to deal with the following types of test plans:

  • Master Plan or Master Test Plan
  • Test Plan (let’s call it a detailed test plan)
  • Product Acceptance Plan is a document describing a set of activities related to acceptance testing (strategy, date, responsible employees, etc.) (RUP Acceptance Test Plan Template)

The distinct difference between the Master Plan Test and the simple Test Plan is that the master test plan is more static because it contains high-level information that is not subject to frequent changes in the testing and review process. The very detailed test plan, which contains more specific information on the strategy, the types of testing, the schedule of work, is a “living” document that constantly changes, reflecting the actual state of affairs on the project.

In everyday life, the project can have one Master Test Plan and several detailed test plans describing the individual modules of the same application.

Review and Approval

To increase the value of your test plan, it is recommended that it be periodically reviewed by the project team. This can be done simply by agreeing with one another or implementing it in the form of an “approval procedure”. As an example, we list the participants of the project group, whose approval we deem necessary:

  • Lead Tester
  • Test Manager (Quality Manager)
  • Head of development
  • Project manager

Each of the listed project participants, before approval, will review and make comments and suggestions that will help make your test plan more complete and qualitative.

Summary

Using the tips above, you will have more chances to write a good document, rather than invent everything yourself.

 

Leave a Reply

Your email address will not be published. Required fields are marked *