91³Ô¹ÏÍø

A large part of the development effort of automotive software has to be invested in the maintenance of tests. During development, software units are often extended with new functions, refactored or errors are corrected. Every change to the behavior, structure and interfaces is tested again. However, a change to the code is usually not without repercussions for existing tests and must therefore also be adapted. In this case one speaks of maintenance in the test.

1. Avoid Redundancies in Test Cases

In coding, it has long been standard practice to avoid redundant implementations by moving code portions to separate functions. In testing, this approach has not yet fully taken hold. Often, test automations contain redundant implementations, which have to be created several times and thus have to be maintained several times in case of changes. This is unnecessary and maximum waste, because it makes your test process slow and expensive. Therefore, use established approaches, like encapsulation, from the field of coding in test automation, as well.  

2. Reduce Complexity Through Structure

Whether in small or large projects, the number of test cases increases daily. Without concrete specifications, this rapid growth quickly leads to confusing structures in test projects. As a result, change requirements for tests must be analyzed at great expense. Create clear rules on how tests are structured and linked to requirements.

3. Avoid Spaghetti Code in Tests

Sounds familiar? Test instructions with 100 and more lines. In terms of maintenance, it then quickly becomes tricky to incorporate the change. This costs valuable time that could be used for testing new functionalities. But first the basis should stand again. There are several approaches to avoid spaghetti code in tests: Abstraction through hierarchization, use of references, parallel modeling of disjoint test inputs, and separating test data from expected values. Your test cases will be shorter, more compact and easier to understand. This has positive effects during creation, review and in case of changes.

4. Avoid Tool Breaks

Every tester will confirm that tool breaks are a pain in the daily doing. A typical example is the test case creation process: the requirements are in the ALM tool, the tests are in the test tool and the tester has to constantly switch between both tools. Once finished, the tester has to manually transfer links/IDs references/test results from the test to the ALM. This is error prone and costs valuable time. Avoid this unnecessary work by creating a stable integration between tools with frequent data exchange. Automate the interface as much as possible.

5. Reuse the Same Tests at Different Test Levels/Stages

Whether model-based development or hand-coding, code is often tested at multiple levels in different environments (e.g., test on Windows and for target hardware). In the worst case, tests are implemented multiple times: this is not necessary. Platform-independent abstraction in test case creation allows them to reuse the same test cases, saving time multiple times. Platform-specific customizations can be easily produced by mapping once.

Conclusion

These approaches are basic principles and part of our test automation TPT. We will explain them to you in detail, so that you can reduce your maintenance efforts to a minimum. You will be impressed by the power of these approaches.