A significant success factor for software testing is having tests that are effective and, at the same time, cost-effective. The imbus TestBench interaction method provides just this: A method with which your tests can be put together from reusable components. In this way, you don’t just save on your budget, you also make test know-how available for your team to call up at any time via these components.
In this process, a simple interaction is a single testing step, in other words the stimulation of the tested system, for example, through the input of data, or the testing of an expected target reaction of the system. Interactions are parametrizable. Each time an interaction is used, you can provide it with different data. This data is described in the imbus TestBench using data types. Simple data types contain values (representatives) distributed to the equivalence classes, and these values are used to stimulate or test the system.
Compound interactions consist of a sequence of interactions that themselves can be either simple or compound. In compound interactions, you can encapsulate the complexity of particular test procedures: You summarize a succession of many test steps in one element with a descriptive name, such as “establish standard condition”. That means that your test specification becomes far more readable, without any loss in the level of detail. Analogous to the compound interactions, there are also compound data types with which you can encapsulate complex data records as simple test elements.
Tests specified in the interaction method, therefore, consist of an interaction sequence with parameters and a table with specific values for the parameters.
The interaction sequence and the parameter table are together referred to as the test case set. To add more test cases to the test case set, you simply have to add another line to the parameter table. To extend the test logic of all test cases, you just have to add interactions to the interaction sequence.
With iTORX, the test designer additionally has a comfortable preview tool available to him for test specification. That means that, at any time, even for multiply nested interaction sequences and data types, he is able to see how the test is specified in detail.
If a detail of the tested system is changed, for example in the course of a new release, it is often the case that only a single test element has to be adapted, so as to update all tests correspondingly.
With value tables (instance tables), you can draw up an enormous number of parameter combinations for the automated test with the minimum of effort. For the specification of manual tests, instance tables can often lead to a significant increase in the readability of the test specification.
All test elements, in other words interactions, data types, and conditions, are filed in the test element tree. There they can be ordered in an easily-understandable tree structure.
The above-described encapsulation makes it possible to divide up the test specification into abstraction levels. That means, for example, that the test specification for the application logic can be clearly separated from the automation layer – but still stays closely linked to it.
Specification work tasks can be divided up, for example, to technical experts, test designers, and test automation specialists – and each one only works in the area that he knows best. It is not necessary that, for example, the specialists for the system under test also know about the details of the test automation.
When working with the imbus TestBench interaction method, the following principle applies: “Small or large cause – smallest possible effect”. It doesn’t matter whether your product specification has only been slightly amended or whether it has been changed completely, the amount of changes needed in your test specification is always as little as possible.