Wie heißt es so schön? “Never touch a running system!” Intuitiv wissen wir: Jede Änderung in der Software birgt das Risiko, neue Fehler einzubauen. Im Idealfall haben wir natürlich das gesamte System, inklusive der neuen Änderungen, mit automatisierten Unit Tests und Functional Tests abgedeckt, so dass dieses Risiko eher klein ist.

Was aber, wenn wir es – wie so oft – mit einem System ohne ausreichende Testabdeckung zu tun haben? Dann hilft Test-Gap-Analyse, eine Methode, um ungetestete Änderungen in der Software systematisch aufzuspüren. Das habe ich auf der SEACON dieses Jahr in einem Vortrag der Test-Spezialisten von CQSE gelernt.

Wenn Sie es nachlesen wollen, das Verfahren ist im Artikel “Erfahrungen mit Test-Gap-Analyse in der Praxis” (ObjektSpektrum 2/2018) dargestellt. Ein paar interessante Beobachtungen aus dem Artikel:

• Betrachtet wurde u.a. ein betriebliches Informationssystem mit ca. 340.000 Zeilen C#-Code. Bei einem Release gingen ungefähr die Hälfte der Anderungen im Code ungetestet in Produktion.
• Wenn man nachträglich die im Produktivbetrieb aufgetauchten Fehler analysierte, zeigte sich, dass Fehler in geändertem, aber ungetestetem Code fünfmal wahrscheinlicher waren, als in ungeändertem Code.
• Es ist schwierig, geänderten Code beim Testen zuverlässig zu erwischen.

Kurz gesagt vergleicht die Test-Gap-Analyse zwei Dinge:

1. Code der geändert wurde, z.B. seit dem letzten Release, oder im Rahmen der Bearbeitung eines Tickets.
2. Code, der bei Tests ausgeführt wurde. Dabei können die Tests sowohl automatisiert als auch manuell gewesen sein.

Die Lücken (gaps) im Test sind dann Stellen im Code (meist: Methoden), die zwar geändert, aber von keinem Test ausgeführt wurden. Wie oben beschrieben, konzentrieren sich hier die potenziellen Fehler, es lohnt sich also, Test-Ressourcen für diese Bereiche aufzuwenden. Das Ergebnis wird grafisch aufbereitet:

Visualisierung von Test-Gaps am Ende der Testphase. Treemap mit den Komponenten des System under Test. Jedes Rechteck repräsentiert eine Komponente. Der Flächeninhalt korrespondiert mit der Größe der Komponente in Zeilen Quelltext. Unveränderte Methoden sind grau dargestellt. Geänderte Methoden, die getestet wurden, sind grün. Neue ungetestete Methoden sind rot, geänderte ungetestete Methoden orange dargestellt. (Abbildung aus dem zitierten Artikel)

Das Verfahren ist für alle gängigen Technologien einsetzbar und, wie gesagt, unabhängig davon, ob Tests manuell oder automatisiert durchgeführt werden. Wie immer beim Testen gibt es auch hier keine Garantie für die Abwesenheit von Fehlern. Es zeigt nur, welche geänderten Bereiche definitiv noch nicht getestet wurden.

Richtig dramatisch werden Lücken im Test bei Hot Fixes (das sind gewissermaßen Notoperationen an Code, der schon im produktiven Einsatz ist). Die Änderungen sollten natürlich sorgfältig getestet werden, auch wenn alle unter hohem Zeitdruck stehen. Aber wer weiß schon genau, ob alle Änderungen aus dem Hot Fix beim Test auch erwischt wurden? Der Blick in die Test-Gap-Analyse zeigt es.

Matthias Berth