BUSINESS DRIVEN TEST MANAGEMENT

Business Driven The key to testing is that tests are executed on the basis of test cases, checklists and the like. But what kind of tests are they? To ensure the tests’ usefulness, they must be set up to test those characteristics and parts of a test object that represents a risk if it does not function adequately in production later on. This means that various considerations have already been made before test execution can begin. In other words, some thought has already been given to which parts of the test object need not be tested, and which must be tested and how and with what coverage. Choices must be made in what is tested and how thoroughly. Such choices depend on the risks that an organization thinks it will incur, the available quantities of time and money, and the result the organization wishes to achieve. The fact that the choices are based on risks, result, time and cost is called business-driven and constitutes the basis for the BDTM approach.

Characteristics of BDTM TMap devotes explicit attention to communication due to the business-driven test management approach. BDTM starts from the principle that the selected test approach must enable the client to control the test process and (help) determine the test approach. This gives the testing an economic character. The required information to make this possible is delivered from the test process.

BDTM has the following specific properties:
  • The total test effort is related to the risks of the system to be tested for the organization.
  • The estimate and planning for the test process are related to the defined test strategy.
  • At various moments in the testing program, the client is involved in making choices.

The steps in BDTM To understand the BDTM approach, it is important to keep an eye on the final objective. Which is to provide a quality assessment and risk recommendation about the system. The steps of BDTM focus on this:
  • Formulating the assignment and gathering test goals. User stories or requirements can be found in the work item repository, together with specific project process requirements is it the basis for the assignments and setting of the test goals.
  • Determining the risk class for each combination of characteristic and object part. The risk is set per user story or requirement. A specific classification field for risk classes can be found on the form. See User story work item type and Requirement work item type.
  • Determining whether a combination of characteristic and object part must be tested thoroughly or lightly. Within the master test plan decisions about the thoroughness of the tests are written down, also what part needs to be tested in which stage. See Master plan section in this guidance.
  • An overall estimate is then made for the test and a planning set up. Within an Agile approach the developers are estimating there tasks for the implementation of the user story, the testing effort is also estimated in this stage.
  • Allocating test techniques to the combinations of characteristic and object part. Beside the estimation also the test techniques are determined, in what way does this pieces of functionality needs to be tested, following which technique are the test cases created? this information is added to the User story work item as a test task and assigned to a tester who is creating these test cases
  • Throughout the test process, the test manager provides the client and other stakeholders with adequate insight into and control options over testproces and test object. Reports about the testing effort, test planning, quality of the test basis and test object are used for this communication. </ol>
tmap processe.png

Advantages of BDTM The advantages of the BDTM approach are:
  • The client having control over the process.
  • The test manager communicates and reports in the terminology of the client with information that is useful in the client’s context.
  • At the master test plan level, detailing can be as intensive as required or possible.

Last edited Nov 10, 2009 at 6:29 PM by ClemensReijnen, version 3

Comments

No comments yet.