Test Impact Analysis Intelligenter testen, nicht härter

Das Software Testing stellt Entwickler vor enorme Herausforderungen. Schwierigkeiten macht vor allem die Wahl des richtigen Zeitpunktes sowie der passenden Verfahren. Mehr Effizienz versprechen in diesem Zusammenhang intelligente Techniken wie die »Test Impact Analysis«.

Berichte aus der Industrie zeigen es immer wieder: Das Testen von Software stellt – selbst in Zeiten von modernen Verfahren wie Agile, DevOps und Continuous Integration/Deployment – nach wie vor einen Engpass im Entwicklungsprozess dar. So testen die Softwareteams in manchen Fällen nicht früh genug und müssen in Folge davon in späteren Entwicklungsphasen mit Bugs und Sicherheitsschwachstellen kämpfen. Bei bestimmten Problemstellungen kann es sich auch anbieten, in einer späteren Phase zu testen, indem die Applikation in einer Produktionsumgebung überwacht wird. Beide Vorgehensweisen führen dazu, dass Unternehmen nach wie vor Deadlines überschreiten. Außerdem leiden Qualität und Sicherheit darunter, was oftmals zu der falschen Annahme führt, dass die neuen Prozesse nicht in der Lage sind, die an sie geknüpften Erwartungen zu erfüllen.

Um diese Probleme zu vermeiden und intelligenter zu testen, setzen einige Unternehmen bereits auf die sogenannte »Test Impact Analysis« (TIA). Sie hilft dabei, besser zu verstehen, was getestet werden muss. Darüber hinaus erlaubt es das datengetriebene Konzept, Tests auf der Zeitachse sowohl nach links, also auf einen früheren Zeitpunkt (Shift Left Testing), oder nach rechts auf einen späteren Zeitpunkt (Shift Right Testing) zu verschieben.

In jedem iterativen Prozess muss beim Testen ein Kompromiss in Bezug darauf geschlossen werden, in welchem Umfang Tests innerhalb eines begrenzten Zeitzyklus durchführbar sind.

Agile, DevOps und der Test-Engpass

So ist es etwa in den meisten Projekten unmöglich, in jeder Iteration einen kompletten Regressionstest durchzuführen. Also beschränkt man sich auf eine bestimmte Zahl von Tests und definiert das, was getestet werden muss, nach bestem Wissen. Oftmals konzentriert sich das Testen zudem auf das Ende eines Zyklus, weil meist erst dann genügend neue, testbare Features implementiert sind. Der resultierende Graph, der den Aufwand im Zeitverlauf abbildet, hat deshalb einen sägezahnähnlichen Verlauf (Bild 1). Das heißt, in jedem Zyklus werden nur bestimmte Tests ausgeführt, bis schließlich im letzten Zyklus ein vollständiger Regressionstest erfolgt.

Kein Projekt erreicht den finalen Zyklus jedoch ohne Bugs oder ohne Sicherheitsschwachstellen. Werden Defekte allerdings erst in dieser Phase aufgedeckt, kommt es unweigerlich zu Verzögerungen, da die Fehler beseitigt werden müssen, um dann anschließend erneut zu testen. Trotz dieser Verzögerungen und des Aufwands bleiben viele Bugs oftmals bis in das finale Produkt hinein unentdeckt (Bild 2).

Das führt dazu, dass das Testen auf der Zeitachse häufig nach rechts verschoben wird, sprich: Man verlegt es in eine spätere Phase. Dabei testen Unternehmen ihre Applikationen oft bis in die Deployment-Phase hinein. So sollen die Testmaßnahmen aufgewertet werden. Außerdem kann man so auch Tests durchführen, die sich erst in der Deployment-Phase bewähren. Dazu zählt etwa die API-Überwachung, das Ein- und Ausschalten von Features in der Produktion oder das Einholen von Feedback aus dem realen Betrieb.