The test plan is one of the most important livrables for a business analyst on a project. It makes you accountable of the release quality and this is a communication stepstone that will focus the attention of the leaders and sponsors on your project.
Too often, the work, even if it’s done seriously, is not enough structured and formalised. As a consequency, the tests results status are communicated as a simple status declaration. In the facts, the tests plan communicate on a status that doesn’t allow to know if the tests cases are relevant and more less if they have been correctly executed.

A quality Test Plan must respect the 7 below pillars:

1. BE EXPLICIT ON THE TESTS CONDITIONS

A Test Plan must identify the conditions under which the tests were performed, the following information must be found:

  •      The Date des runs de tests ;
  •  The Environment Execution Description (the Server ID, the Data base ID …) ;
  •  The Version of the Binary ;
  •  The Data version (data base copy audit date time for example) and the set-up version ;
  •  The names/ID of the corresponding Specifications and the version of those specifications. 

2. GIVE A CLEAR TEST STATUS AND AN HIGHLIGHTED EXECUTIVE SUMMARY

A test plan must give a crystal clear status, it must be synthetic and global for giving to the management the right alert level and to permit them to go from the global to the unit testing if necessary.

3. BE FOCUSED ON THE FACTS

In a quality test plan, we expect to find elements that:

  •   Allow to identify to uniquely identify the test on the environment (trade id …) ;
  •   Allow to identify the part of the specification that is currently being tested ;
  •   Proof the inputs, the parameters and the elements controlled in the test case (screenshots, extractions). 

4. COMPARE RESULTS TO EXPECTED RESULTS

The test strategy has to be thought in the earliest phases of the project. As the purpose of the test plan is to check that the specifications points have been correctly developed, each test must have a known expected result.

5. SHARE TRANSPARENT RESULTS

The test plan result must be shared with all the project stakeholders, whatever the test result. The sharing action allow you to share the risk with the other stakeholders and allows the managers to take the appropriate actions if they have the right level of information.

6. GIVE EXPLICIT AND FACTORIZED TESTS SCENARII

  •   Each test case must be fully explicit for the tests to be easily rerunned or just followed by anyone involved in the project ;
  •   Test cases factorization allow to reduce the number of tests cases to run and to consider that a test or a group for tests will validate a larger part. It will give transversal point of view to the test plan.

7. GIVE TEST CASES THAT CAN BE RERUNNED

A test plan must be rerunnable in the same execution conditions. For the same inputs we expect the same outputs. If we do not get the same result, we will have to analyze the gaps between the two tests runs.
This methodology certainly implies a certain formalism but it allows also you to be able to rationalize those tests and to be able to automatize those tests as a non regression ones.

At the end, the cost of non regression testing phase will become a cost of maintenance of the test plan that will be cheaper, and it will also enhance the release quality by insurring a larger test covering that what can be done manually.
It will take out a huge work charge for the business analyst that will be able to use this time to focus on the test comparison et to have objective results to compare.
In the testing phase, you have to consider that all that have not be tested is not working fine.

The test plan methodology rationalization will have a clear, true and mesurable impact on the release’s quality.

The seriousness brought in the rigor around the communication around the test plan will also have a very positive impact on the qualitative perception of the work of the business analyst.