Test Intelligence bezeichnet Analyse-Techniken, die Daten aus dem eigenen Entwicklungs- und Testprozess auswerten, um mehr Fehler in weniger Zeit zu finden. Konkrete Methoden sind Test-Gap-Analyse (ungetestete Änderungen vor dem Release sichtbar machen), Test-Impact-Analyse (nur relevante Tests nach einer Änderung ausführen) und Test-Suite-Minimierung (optimale Teilmenge aus großen Test-Suites berechnen).
Das Wichtigste in Kürze
- Test-Gap-Analyse kombiniert Versionskontrolldaten mit Coverage-Profiling, um ungetestete Änderungen vor einem Release sichtbar zu machen und bewusste Entscheidungen zu ermöglichen.
- Coverage Profiler zeichnen manuelle Tests genauso lückenlos auf wie automatisierte Tests, ohne dass Testerinnen und Tester ihren Ablauf ändern müssen.
- Test-Impact-Analyse findet in einem Prozent der Gesamtlaufzeit achtzig Prozent der Fehler, die die vollständige Testsuite finden würde, und liefert damit deutlich schnelleres Feedback.
- Historisch gewachsene Testsuites testen gleichzeitig zu viel und zu wenig: viele Tests überschneiden sich stark, während echte Lücken unbemerkt bleiben.
- Auch ein gut besetztes, erfahrenes Entwicklungsteam schafft es ohne dedizierte Werkzeuge nicht zuverlässig, alle Änderungen im Test abzudecken, wie eine interne Studie bei CQSE gezeigt hat.
Was Test Intelligence bedeutet
Test Intelligence ist ein Sammelbegriff für Analyse-Techniken, die Daten aus dem eigenen Entwicklungs- und Testprozess auswerten, um mehr Fehler in weniger Zeit zu finden. Der Ansatz zapft Quellen an, die in jedem Projekt ohnehin entstehen: das Versionskontrollsystem mit allen Änderungen am Code und die Testabdeckung, gemessen über Coverage Profiler.
Elmar Jürgens ordnet darunter mehrere konkrete Analysen ein, die sich gegenseitig ergänzen. Keine davon ist Selbstzweck. Es geht jeweils um eine bessere Entscheidungsgrundlage: Was muss getestet werden, was lohnt sich, was kann weg.
Der gemeinsame Nenner ist die Kombination aus statischer und dynamischer Sicht. Wo eine statische Analyse den Code liest, ohne ihn auszuführen, zeichnet ein Coverage Profiler auf, was bei einem Testlauf tatsächlich durchlaufen wird. Erst die Verbindung beider Datenquellen macht die Aussagen belastbar.
Wie die Test-Gap-Analyse ungetestete Änderungen sichtbar macht
Die Test-Gap-Analyse zeigt dir vor einem Release, welche Code-Änderungen noch nicht getestet wurden. Die Grundannahme: Bei langlebiger Software stecken die meisten Fehler an den Stellen, die sich seit dem letzten Release verändert haben. In einem komplexen Team ist aber schwer nachzuvollziehen, ob wirklich jede Änderung im Test erwischt wurde.
Dafür werden zwei Datenquellen übereinandergelegt. Die Änderungen kommen aus dem Versionskontrollsystem und zeigen, was sich seit einem Referenzpunkt verändert hat, etwa seit dem letzten Release oder dem letzten Testlauf. Die Testabdeckung kommt aus Coverage Profilern, die alle Testphasen lückenlos aufzeichnen.
Wichtig dabei: Aufgezeichnet werden nicht nur automatisierte Unit- und End-to-End-Tests, sondern auch manuelle Tests. Dem Coverage Profiler ist es egal, ob er einen automatisierten oder einen manuellen Test beobachtet. Der Tester muss seinen Ablauf nicht ändern, die Aufzeichnung läuft im Hintergrund.
Das Ziel ist nicht, alles zu testen. Das Ziel ist eine bewusste Entscheidung. Manchmal darf eine ungetestete Änderung in Produktion, weil das betroffene Feature erst in Monaten gebraucht wird. Oft ist das nicht so, und dann zeigt die Analyse rechtzeitig, wo eine Lücke klafft.
Auch wenn aus irgendeinem Grund in den letzten Jahrzehnten Coverage Profiler vor allem für automatisierte Tests eingesetzt wurden, machen wir das seit über zehn Jahren mit Kunden auch für manuelle Tests. Das funktioniert sehr gut. — Elmar Jürgens
Coverage Profiler arbeiten je nach Technologie unterschiedlich
Für jede verbreitete Technologie gibt es einen passenden Profiler, kommerziell oder Open Source. Grob lassen sich drei Kategorien unterscheiden.
- Profiler an der virtuellen Maschine: genutzt für Sprachen wie Java, C#, Python und für SAP ABAP. Sie docken an die VM an und beobachten von dort, was zur Ausführung kommt.
- Instrumentierende Profiler: verändern den Code selbst, indem sie zwischen Statements eigene Anweisungen einfügen, die melden, dass eine Stelle ausgeführt wurde. Dieser Weg wird für C und C++ gewählt, wo es keine virtuelle Maschine gibt, an die man andocken könnte.
- Hardware-Profiler: für eingebettete Systeme. Manche Prozessoren haben eigene Pins, an die ein Hardware-Profiler andockt. Sie geben eine Hardware-Garantie, dass sie das Timing nicht beeinflussen und sich der Prozessor exakt wie ohne Profiling verhält.
Die Wahl richtet sich danach, was für die jeweilige Technologie am besten funktioniert. Für manche Sprachen entstehen eigene Profiler, weil es keine brauchbare Alternative gab.
Warum der Performance-Impact in der Praxis klein bleibt
Sehr feingranulares Instrumentieren kann die Laufzeit deutlich ausbremsen, aber für die Test-Gap-Analyse ist diese Feinheit gar nicht nötig. Es muss nicht festgestellt werden, ob jeder einzelne Pfad in einer langen Methode durchlaufen wurde. Es reicht zu wissen, ob eine Methode überhaupt betreten wurde.
Wenn eine Methode gar nicht betreten wird, genügt ein einzelnes Bit. Das erzeugt nicht nur weniger Daten, sondern auch deutlich weniger Performance-Last. Benchmarks mit verschiedenen Profilern zeigen häufig rund ein Prozent Slowdown, manchmal fünf Prozent.
Im manuellen Test merkt man davon nichts. Dort wartet das System ohnehin meist auf Netzwerk oder Datenbank, und an diesen Stellen bremst das Profiling nichts aus.
Selbst gute Teams decken ihre Änderungen nicht vollständig ab
Auch disziplinierte Entwicklungsteams schaffen es nicht zuverlässig, ihre Änderungen im Test vollständig abzudecken. Das liegt nicht am fehlenden Willen, sondern daran, dass es ohne dedizierte Werkzeuge schlicht zu kompliziert ist.
Eine Studie im eigenen Unternehmen untermauert das. Die Ausgangslage war günstig: eine kleine, stabile Gruppe ausgebildeter Informatiker, dazu ein flächendeckendes Code-Peer-Review, bei dem jede Änderung von einer anderen Person geprüft wird, bevor sie ins Release darf. Untersucht wurde, ob es gelingt, fremden, gerade reviewten Code mit Tests korrekt abzudecken. Selbst unter diesen Bedingungen gelang das nicht.
Wenn schon in einem überschaubaren, gut aufgestellten Team Lücken bleiben, dann sind sie in großen, historisch gewachsenen Systemen die Regel. Genau hier setzt die Analyse an, statt sich auf das Bauchgefühl zu verlassen.
Wie die Test-Impact-Analyse schnelles Feedback zurückbringt
Die Test-Impact-Analyse wählt aus einer großen Testsuite genau die Tests aus, die durch deine letzten Änderungen betroffen sind. Das verkürzt die Feedback-Schleife drastisch.
Das Problem dahinter kennen viele Teams: Mit der Zeit kommen immer mehr automatisierte Tests dazu, und die Gesamtlaufzeit wächst. Ein Kunde hat 80.000 automatisierte End-to-End-Tests, die hintereinander ausgeführt rund 400 Stunden brauchen. Selbst stark parallelisiert vergehen oft mehrere Tage bis zum Ergebnis.
Spätes Feedback verliert seinen Wert. Wenn etwas heute kaputtgeht und du es sofort erfährst, weißt du, woran es lag. Kommt das Feedback erst nach einem Monat, hast du vergessen, was du gemacht hast, und dazwischen liegen viele weitere Änderungen, die ebenso schuld sein könnten.
Die Lösung: Jeder Testfall wird einmal einzeln vermessen. Danach lässt sich nach einer Änderung gezielt sagen, welche Tests jetzt laufen müssen. Die Ergebnisse sind deutlich: In rund einem Prozent der Gesamtlaufzeit findet die Auswahl 80 Prozent der Fehler, die die ganze Suite finden würde, in zwei Prozent der Zeit sind es 90 Prozent.
Ein kleiner Teil rutscht durch, deshalb bleibt der vollständige Testlauf gelegentlich nötig. Der Großteil neuer Fehler taucht aber sehr schnell auf. Eingebaut wird das in die Continuous-Integration-Pipeline, ohne dass bestehende Tests umgeschrieben werden müssen. Das hilft besonders Teams, die keine saubere Testpyramide haben und auch keinen einfachen Weg dorthin.
Historisch gewachsene Testsuites machen gleichzeitig zu viel und zu wenig
Testsuites wachsen wie die Software selbst, und das führt zu einem Paradox: Vieles bleibt ungetestet, während gleichzeitig viele Tests fast dasselbe prüfen wie andere. Redundanz entsteht oft durch Copy-Paste mit kleinen Änderungen, gerade bei End-to-End-Tests.
Die Pareto-Optimierung adressiert das, indem sie aus einer großen Testsuite eine kleine extrahiert, die in einem Bruchteil der Zeit einen großen Teil der Fehler findet. Diese kleine Suite eignet sich als Quality Gate, bevor man einen teureren Testlauf startet.
Der Nutzen wird dort konkret, wo Tests teuer sind. Bei Hardware-in-the-Loop-Tests mit Werkzeugmaschinen lässt sich nicht beliebig parallelisieren, weil die teure Maschine physisch vorhanden sein muss. Die Software muss erst gut genug sein, um auf diesen Lauf zu dürfen. Ein Fehler, der 1.000 von 5.000 Tests umfallen lässt, verdeckt sonst alle anderen.
Statt eine Akzeptanz-Suite von Hand zusammenzustellen, berechnet die Optimierung für ein gegebenes Zeitfenster die Suite, die in dieser Zeit am meisten Fehler findet. In Studien mit Kunden fand der berechnete Satz doppelt so viele Fehler in derselben Zeit wie die handgemachte Auswahl.
Auch beim Sparen von Ressourcen zahlt sich das aus. Wer Tests in der Cloud ausführt, etwa auf AWS, zahlt mit jeder Ausführung mehr, je mehr Tests dazukommen und je häufiger sie laufen. Eine kleinere, gezielte Suite senkt diese Kosten direkt.
Akzeptanz entscheidet, nicht das Werkzeug
Ein Analysewerkzeug entfaltet nur Wirkung, wenn das Team es auch nutzt, und das erfordert Change Management. Das gilt für statische, dynamische und hybride Analysen gleichermaßen. Hybride Analysen kombinieren statische und dynamische Sicht.
Vom Messen allein wird nichts besser. Jedes Team braucht eine Schleife, in der klar ist, was das Werkzeug leistet und was nicht. Dazu gehört, die Sorge vor persönlicher Leistungskontrolle proaktiv anzusprechen, bevor überhaupt etwas gemessen wird. Diese Befürchtung schwingt bei Analysen oft mit.
Genauso wichtig ist die nahtlose Einbettung. Die Informationen sollten in den Tools auftauchen, in denen ohnehin gearbeitet wird: im Testmanagement-Tool für Tester, in der IDE und im Pull-Request für Entwickler. Ein Werkzeug, das über den Zaun geworfen wird, verpufft.
Wer Werkzeug, Einführung und Support aus einer Hand liefert, verkürzt zudem die Flüsterpost zwischen Anwender und Entwicklungsteam. Wenn die Leute im Support selbst am Werkzeug mitentwickeln und es selbst einsetzen, kommt Feedback direkter zurück, und Qualitätsprobleme bemerkt man am eigenen Produkt zuerst.
Wohin sich Test Intelligence entwickelt
Dieselbe Technologie, die im Test misst, lässt sich auch in Produktion einsetzen, um zu sehen, was Anwender tatsächlich nutzen. Das deckt in historisch gewachsener Software oft Funktionalität auf, die seit Jahren niemand mehr braucht.
Solchen toten Code zu löschen spart doppelt. Du sparst Aufwand im Test und in der Entwicklung. Wenn eine statische Analyse eine Sicherheitslücke in einem Bereich findet, der gar nicht mehr gebraucht wird, ist Löschen billiger als mühsames Reparieren.
Auf der Roadmap stehen weitere Datenquellen. Requirement- und Test-Smell-Analysen lesen sprachliche Anforderungen wie eine statische Analyse, etwa auf Passivkonstruktionen oder schwammige Wörter. Solche Formulierungen führen zu unterspezifizierten Testfällen, die unterschiedliche Personen verschieden interpretieren, und damit zu nicht-deterministischen Tests. Ein mehrdeutiges Requirement lässt offen, wie es am Ende implementiert wird.
Ein weiteres Feld ist Requirements Tracing. Wer als Werkzeug ohnehin in allen Systemen sitzt, kann Verifikationsmatrizen aus Requirements, manuellen und automatisierten Testfällen sowie Code generieren. Bei jedem Pull-Request wird sichtbar, wenn sich ein Requirement geändert hat und was das für Code und Tests bedeutet. So entsteht die Matrix nicht erst nachträglich für einen Auditor, sondern die Artefakte bleiben kontinuierlich konsistent.
