A better way to Test – 5

A better way to Test – 5

In our last blog we discussed how more testing or a higher percentage of test case coverage does not necessarily lead to better testing. We did not, however, provide a solution to the problem.

One of the first items is to classify the testcases. In a project of any size, with numerous testcases, it is difficult to determine what each testcase is doing without classifying them. The Test Management tools allow for a lot of this and it is usually simply a matter of selecting the fields you want to use for classification; providing a limited list of choices for most of the fields (some can be freeform text entry but some need to have a limited number of choices so as to allow classification) and deciding where each testcase belongs. It will not be perfect the first time but can be refined over time. Some items that can be used for classification are as follows:

1. Requirements (this comes out of Traceability).
2. Function tested (may be a subset of the Requirements or it may be a separate mapping).
3. Date of testcase creation (just so you know how old it is).
4. Priority of the testcase.
5. Some statistics generated from the testcase execution.
6. The risk it tests – we have rarely seen this explicitly listed.

The last item is the most important if you are testing against risk. It presupposes that you have the Risks listed, classified and numbered. Then it is a reasonably easy process to link the testcases.

When your project is over, you can determine if the testcases addressed the risks (where appropriate) and whether they are useful for next time.

Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Testing can be better.
Contact us for further information.