3 principle documents in Testing

Share this post
FaceBook  Twitter  Mixx.mn     

  There are 3 principle documents in Testing:

 1)        1) Test Policy

 -      2)    Test strategy

       3)    Test Plan

1. Test Policy (Organization Level)

  Test policy document covers followings points:

         1.       Very High Level Document

         2.       What “Testing” means for organization

         3.       How organization measures test success

         4.       Relatively static document (Changes when organization’s focus changes)

         5.       Developed by IT department

 2) Test Strategy:
It is a company level or Programme Level document  and developed by QA category people like QA and PM. This document defines "Testing Approach" to achieve testing objective. Test strategy is the freezed part of BRS (Business requirement specification) from which we get Test Policy and Test Strategy.

Components in the Test Strategy are as follows:

      1.        Applicable for a Programme/System which covers multiple projects

      2.       Scope and objective of Testing : The purpose of testing in an organization

      3.       In scope/Out of scope Items for testing

      4.       Business issues : Budget control for testing

      5.       Roles and responsibilities : Names of jobs in the testing team and their responsibilities

      6.       Communication and status reporting : Required negotiation between two jobs in a team

      7.       Test Levels (Unit/Module/System/Integration)

      8.       Test Types ( Functional/Non-Functional)

      9.       Entry/Exit/Stop/Resumption Criteria for testing (for different Levels/Phases)

      10.   Test Environment

      11.   Test case design methodology (Specification driven/BVA/EQ Partition)

      12.   Test methodology ( Top-down/bottom-up/risk based)

      13.   Test deliverable

      14.   Test approach : That is the TRM ( Test responsibility Matrix)

      15.   Test automation Approach and tools : Availability of testing tools and purpose of automation

      16.   Testing measurements and metrices

      17.   Test Tools to be used

      18.   Defect Management approach : required negotiation between testing and development teams

      19.   Defect classification

      20.   Retesting & regression approach

      21.   Risks to be addressed

      22.   Risks and mitigation : Expected failures during testing and solutions to overcome

      23.   Change and configuration management: How to handle sudden changes in customer requirements.

      24.   Training plan

3) Test Plan:
Test plan is a Project Level  document. Test plan is the freezed document developed from SRS (Software requirement specification), FS (Functional specification), and UC (use case). After completion of testing team formation and risk analysis, Test Lead is preparing test plan document in term of:

      1)      What to test?
2) How to test ?
3) When to test ?
4) Who to test?

There is one Master Test Plan consists of reviewed Project Test Plan and Phase Test Plan. So there is general talk about Project Test Plan.
Components are as follows:

1 ) Test plan ID : Unique number or name
2) Introduction : About project
3) Test Items: Names of all modules in the project.
4) Features to be tested:
5) Features not to be tested:
6) Testing approach: finalized TRM, selected testing techniques
7) Entry Criteria : When testing can be started
8) Exit Criteria : when testing can be stopped
9)Fail or Pass criteria:
10) Test Environment : The environment where the test is to be carried out.
11) Test Deliverable:
12) Staff and training needs
13) Roles and Responsibilities
14 ) Project Schedule  : starting and End dates
15) Risks and mitigation.

16) Approach


Test strategy VS test plan (Summary):-

The test strategy is a road map which tells how you are going to address testing for the project from the start to end. Some companies have a strategy or approach section in the test plan, others have a separate document.

The test plan will detailed that out because it’s written at a later stage of the project.  IT describe what to test?, how to test ? , when to test? Who to test?

 A Test Plan describes the approach, Features to be tested, Testers assigned, and whatever you plan for your project.



In other way the following points must be covered in some way either in testing reference documents:
•Vision -> vision, goals, objectives
•Mission -> Organization's intention, strategy, tactics, policies, rules
•Baseline -> baselines (SWOT), maturity, capability, influencers (roles)
•Requirements -> constraints, assumptions, out of scope, dependencies, risks, issues, problems, incidents, defects
•Governance -> decision making, follow up, communication plan, meeting plan
•Resources -> QMS (processes, activities, tasks, templates, guidelines, checklist, standards, glossaries, tools, ...)
•Practice -> pragmatic approach (who does what, when , where and how)
•Improve -> problem solving, defect solving (how do we handle problems, defects)
•Measure -> definition of what we will measure and why
•Track-> based on measurement we define what we track and how we can pave the track (road map)
•Guide-> training, mentoring, coaching, e-learning, handover, ...
•KPI-> uniform management information gathering. GQM - each goal from the vision part raises a number of questions that lead to measurements. A KPI is a function of all these measurement (sum, average, footprint (radar), etc.)
•End Result->Final conclusions, GO/NOGO criteria/reporting, lessons learned