AI-supported test automation in automotive software development: Testomat
Test teams evaluate hundreds of test logs manually, maintain regression suites by hand and spend long alignment rounds assigning defect reports. We build the Testomat assistant, which automates five recurring testing tasks – sign-off stays with the test engineer in every module.
The situation
Testing vehicle software continuously produces work that requires no engineering knowledge but consumes engineering time: sifting logs from unit, integration and HiL levels, adapting regression suites to every change, assigning incoming defect reports to the right component, writing reports to template.
Meanwhile the real substance is often left undone: the links between tests and requirements are patchy, and which tests a specific change actually needs is decided by caution rather than analysis – the whole suite runs.
Typical data basis
Requirements and their links to existing test cases – traceability data, to the extent it is maintained. Existing test cases, test scripts, test records and logs from unit, integration and HiL levels. The defect database, for instance Jira, with historical tickets and their component assignments.
On top of that, the software's change history – commits, change requests, dependencies between modules – and test coverage figures from the automated CI tests.
Why such initiatives fail
Heterogeneous formats. Logs from different test levels follow no common schema. Without clean unification, nobody evaluates them automatically.
Patchy traceability. The links between tests and requirements partly have to be reconstructed before test case generation and regression selection can build on them.
Regression selection without change analysis. Which tests are relevant depends on which components a change affects. Without a sound analysis, running the full suite is the only safe option.
Ambiguous failure patterns. The same symptoms can have several causes – and a wrong assignment costs more time than none at all. Silent misassignments are the most expensive outcome.
Approach
Test case proposals. From requirements, a language model generates test case drafts in a fixed schema that mirrors the target structure of the ALM system – the proposals can be imported without rework. For HiL test cases, the system retrieves comparable existing test cases and the corresponding test rig documentation before generating, so the drafts match the customer's conventions. A second instance checks every draft against the originating requirement and flags proposals that cover nothing new. The test engineer adopts or discards.
Traceability reconstruction. We restore missing links in three steps: matching via naming and numbering conventions, semantic comparison of test descriptions against requirement text, and confirmation of the remaining uncertain cases by the test engineers. The result is a documented trace matrix that can also serve as ASPICE evidence.
Regression selection. A change analysis determines the affected modules from the call graph and the history of co-changed files. On that basis and on historical defect data, a ranking model scores which tests are most relevant for a specific change. The selection runs in the CI chain; safety-relevant tests always stay in scope, independent of the ranking.
Log evaluation and defect classification. A parser converts the log formats of the test levels into a shared results schema and flags deviations. A classifier assigns incoming defect reports to component and defect class – with a confidence score. Below an agreed threshold the system does not assign but presents the triage team with the three most likely assignments and the most similar historical tickets.
Reporting. Test reports are generated automatically from the structured results, following the customer's templates.
What you get
Anomalies instead of log piles: evaluation runs largely automatically – test engineers concentrate on the results that genuinely need attention.
Test with focus: regression runs concentrate on relevant tests and cut unnecessary rig and compute time.
Defects reach the right team sooner: anomalies land with the responsible team earlier. Traceability included: the reconstructed trace matrix closes an existing gap and strengthens the evidence for the ASPICE assessment.
We make this measurable through three quantities collected in the pilot: the share of adopted test case proposals, saved rig time per regression run at unchanged defect detection, and the hit rate of defect classification above the confidence threshold.
Where our experience comes from
We have modelled test rig and defect data for automotive customers – from predicting test bench durations to forecasting defects in running vehicle programmes.
Last updated: 13 August 2026
