In testing, there are various requirements for the specification or presentation of tests.

On the one hand, the test designers want to specify very compactly, not use repetitions and, in the case of data-driven tests, simply provide the necessary data as a table or as an attachment. On the other hand, the testers want to concentrate on the test object and its reactions and not on what they must test in detail.

In the end, purely text-based test specifications do not really satisfy either side, because there is either a lot of text that is difficult to read or a short description that is more like a test idea than a finished test case. Alternatively, the test is described in such detail, with exact test steps, that the technical content and the actual purpose of the test are very difficult to recognise.

In the end, the tests are not repeatable because details are missing, not maintainable because many redundancies and details are hidden in the text or no longer understandable because the technical context of the many small steps is not comprehensible.

This dilemma can be solved by providing test designers and testers with a view of the tests that suits them. To this end, TestBench provides a wizard to support manual testing, which is presented below.

The Test Task

Let’s assume the test task is the following:

Test the possible configurations of vehicles and the calculated prices

The vehicle price is calculated as follows: The basic price of the vehicle is taken as the starting point. The individual prices of the optional add-ons and the price of the special model are added to this.
Additional equipment that is already included in the selected special model is not charged again.

If three or more optional add-ons (which are not included in the selected special model) are selected, a quantity discount of 10% is applied to these optional add-ons. With 5 or more optional add-ons, the quantity discount increases to 15%.

The discount explicitly granted by the dealer relates to the basic price of the vehicle and the prices of the optional extras.
It is not possible to cumulate the volume discount and the dealer discount on the additional equipment; a decision is made between the dealer discount and the volume discount by applying the higher discount in each case.

Examples of possible discount combinations:

The description of the tests

A possible test case would be:

The sequence can be read easily as it consists of individual, clear steps. However, the data contained must be identified when reading. This could be improved by formatting, but at the latest when new combinations of data become necessary, e.g. to achieve a new discount level for the additional equipment, the sequence must be copied and read again more precisely during the test execution.

It therefore makes sense to at least extract the data from the test sequence:

The test sequence now separates the data, which makes it much easier to execute the test if the sequence of steps is known after multiple executions and only the associated data needs to be read. However, the disadvantage remains that the tests must be copied if there are many combinations of data, resulting in many identical tests. This is a disadvantage at the latest when changes or extensions are made, resulting in error-prone search & replace actions.

The dilemma with maintenance can be resolved by extracting the data into a table:

In the test sequence, the specific data has been replaced by parameters for which the following table would then be conceivable:

Now the test can be described very well, changes to the test sequence only need to be made in one place and new test cases, as a new combination of data, can be recognised quickly and easily.

Now, however, the test execution is at a disadvantage again, because the process and data are separate and must be brought together during the test execution. In our simple example, this may still work well, but a technically difficult procedure with many parameters per test step now causes problems during execution, as parameters are mixed up during reading, lines are swapped, and incorrect values are read. The concentration is again spent on reading the test specification and not on the reactions of the test object.

TestBench provides an assistant to solve this problem: iTORX.

The iTORX assistant displays the test steps and the associated data in such a way that it is always clear during test execution what is to be tested with which data.

If the Keyword-Driven Testing method is used to specify the tests, iTORX utilises its possibilities even better.

The Presentation of the Tests

In TestBench, our example using keyword-driven testing is displayed as follows:

The necessary parameters are defined in the parameter list of the test, as the values that are used in the data table are stored in the data types:

The data table for this test is then:

This presentation and organisation of the information is optimal for the specification of the tests, but not for the execution of the tests.

The Assistant iTORX

This is where the iTORX assistant comes into play: The presentation of a test is prepared for the testers in such a way that all data is summarised at the beginning of the test execution of a new test case and then the testers are guided step by step during the actual test procedure.

For each test step, its description and the necessary data are displayed so that no search is required. If required, the data can also be copied to the clipboard with a simple click so that no error-prone retyping is necessary.

In our example, an add-on part must be selected several times for the add-on list:

Such loops are rolled out in the test sequence in iTORX and displayed as a repetition of the associated steps. Each step is assigned the correct values for its parameters:

Each step can be evaluated and assigned a result. Not only pass or fail are available but also other result statuses that consider special situations in the test:

In addition to the assessment of the actual test, further information such as comments can be stored, attachments added, and errors recorded. A total of 14 sub-areas are available, each of which contains special information or can be stored there. The user interface can be customised and positioned using these sub-areas.

iTORX provides some larger and smaller auxiliary functions that optimally support manual testing and help to focus on the test object and not on the interpretation of the test specification.

The assistant can be called up directly from TestBench but can also be used offline without a connection to the TestBench system. To do this, the tests can be exported from TestBench and loaded and processed by iTORX. Test results and all other collected information can be imported back into TestBench.

This is why the assistant bears its special name:
iTORX = imbus Test assistant for Offline und Remote eXecution

Offline use is licence-free so manual test execution outside TestBench is free of charge. For example, brake tests in high-speed trains or acceptance tests on-site in medical facilities are possible without having to rely on a connection to the TestBench system.

TestBench can connect to almost any test automation software. Their result protocols are generated via the connection to this automation software in a format that can also be read by iTORX. This makes it possible to open the test results of test automation runs independently of the TestBench system and to supplement or correct them before they are transferred to TestBench.
Test automation runs usually contain not only individual test cases but possibly thousands of test cases with millions of test steps, as they run overnight or over a weekend. The iTORX can also cope with such data volumes.

The Development Continues

iTORX is a Java-based tool and must therefore be installed.
To avoid this in the future, a new version is currently being developed that runs in the browser but can still be saved as an app. This means that the well-proven offline capabilities will be retained, combined with the advantages of a website.

Here is a preview of the future iTORX:

Conclusion

An assistant that clearly shows me all the test steps to be carried out with the associated parameters and data offers numerous advantages:

#Timesaving:
Manually collecting test data and parameters can be time-consuming. An assistant that provides this information can significantly reduce preparation time.

#Precision:
Humans can make mistakes, especially when it comes to noting down complex or extensive test parameters. An assistant reduces the risk of human error by providing accurate and consistent information.

#Increased efficiency:
With clearly defined steps and parameters, I can focus on performing the tests instead of spending time interpreting or searching for information.

#Standardisation of test processes:
Such an assistant ensures that all testers use the same steps and data, leading to more consistent and comparable test results.

#Better test coverage:
An assistant can help to ensure that all relevant test cases are covered by reminding me of different scenarios and constraints.

#Faster identification of bugs:
As I spend less time on preparation, I can spend more time on the actual testing and identifying bugs.

#Easier repeatability of tests:
In later test phases or regression tests, it is easier to repeat tests because all steps and required data are already clearly defined.

#Better documentation:
An assistant that documents test cases and results facilitates tracking and reporting, which is important for quality control and audits.

#Learning support for new testers:
An assistant that provides clear instructions can also serve as a learning tool for new testers who are not yet familiar with the test procedures and software.

Overall, such an assistant significantly improves the quality and efficiency of the manual testing process while reducing the burden on testers.