BDTM - Business Driven Test Management

In TMAP NEXT the Business Driven Test Management (BDTM) approach for test managers in V-model based projects was described. 
For test managers that work in such a sequential IT delivery model this approach may still be very valuable.

This approach promotes communication between the IT delivery team and the client in the language of the client (related to goals and risks).
By focusing on the four BDTM aspects (Result, Risk, Time and Cost) testing gets a business focus.
The advantages of this approach are:

• The test process is transparent to the client and the client can control the test process on the basis of the four BDTM aspects.
• The test manager communicates and reports using the terminology of the client, with information that makes sense in the client’s context.
• The master test plan can be as detailed as desired or possible; this influences the amount of effort that is required to organize and perform the testing.

The final goal of testing is to supply information about quality and the related risks to the client. Since it is impossible to test everything, an adequate assessment can only be achieved by dividing the test effort (time and cost) as adequately as possible over the parts and characteristics of the test object. The figure below shows the 6 steps of BDTM.

Step 1: Establishing an assignment and collecting test goals
The client formulates the assignment, taking account of the four BDTM aspects: result, risk, time and cost.
Establishing the test goals aims to determine what, in the eyes of the client, are the desired results of the testing activities. A test goal is a success criterion for the test assignment specified in the client's language. The result of this step is the formulation of the assignment and a test goal table.

Step 2: Determining the risk class 
Based on a product risk analysis, it is established what must be tested (object parts) and what must be examined (characteristics). The risk class related to the test goals and the relevant characteristic is established for each object part. If multiple test levels are involved, the test levels that must be set up are determined in a plan that covers all test levels (the Master Test Plan).The test strategy also defines, for each combination of a characteristic / object part, an indication of the relative intensity of testing in a specific test level.
This step results in a risk table.

The steps 3 and 4 are an iterative process.

Step 3: Determining the test intensity 
Deciding whether a combination of characteristic and object part must be tested lightly, moderately, or intensely. This is called the test intensity. The risk class for each object part as defined in the previous step is used as a starting point to determine the test intensity. The principle followed here is: the greater the risk the more intense the required testing.

Step 4: Estimation, planning and feedback 
An overall budget is established for the test, which is plotted in a planning. This is agreed with the client and other stakeholders and, depending on their views, adjusted if necessary. In the latter case, steps 3 and 4 are repeated. This gives the client emphatic control of the testing process, enabling them to manage it on the basis of the balance between result and risk versus time and cost.

End of iteration

The steps 3 and 4 result in a test strategy table.

Step 5: Allocating test design techniques 
If the client and other stakeholders agree to the budget and planning the test intensity is translated into concrete statements regarding the desired coverage. This involves allocating test design techniques to the combinations of characteristic / object part, taking account of circumstances such as the available test basis. The techniques are used to design the test cases at a later stage.
This step results in a test design table for each test level.

Step 6: Providing insight and control options 
Throughout the test process, the test manager provides the client and other stakeholders with adequate insight into and control options for the IT Governance aspects:

• Result: (the test goals achieved)
• Risk: (the risks covered)
• Time: whether the end date- or deadline - is realized) 
• Cost: (whether the test project remains within the agreed budget)