Testautomatisierung – so gehts

Betrachtet man den heutigen Stand der Qualitätssicherung für Software, wird man geneigt sein festzustellen, dass mit zunehmender Komplexität die manuelle Durchführung von Testfällen ansatzweise auf verlorenem Posten steht. Dies hat primär zwei Gründen: Zum einen sieht man sich mit der Tatsache konfrontiert, dass mittels fehlerhafter Produkte fehlerfreie Produkte realisiert werden sollen. Zum anderen steigt der Grand der negativen Seiteneffekte bei zunehmender Komplexität undefiniert an. Da diese Seiteneffekte erst mit geeigneten Tests identifiziert werden können, steigt auch die Anzahl der durchzuführenden Testfälle entsprechend an. Diese Spirale aus bestmöglicher Testabdeckung und Bewusstsein gegenüber dem immanenten Risiko führt zu einer exorbitanten Anzahl von Testfällen, die aus manueller Sicht nur schwer zu handhaben ist. Priorisierung der Testausführung und Ausbau der Testmannschaft reduzieren das Problem nur bedingt.

Interpretiert man die Software-Entwicklung als Teil einer Lieferkette innerhalb eines Produktionsprozesses, drängt sich das Bild einer Stahlwalzstrasse auf. Am Anfang der Walzstrasse wird das Blech mit einem maximalen Druck in die Walzstrasse reingepresst. Am Ende der Walzstrasse wird das gewalzte Blech mit der maximalen Geschwindigkeit herausgezogen. Die Qualität der Bleche wird während des Produktionsprozesses kontinuierlich und ohne Unterbrechung geprüft. Aus Erfahrung kann ich sagen, dass das mathematische Modell einer solchen Software sehr komplex ist und zusätzliches Fingerspitzengefühl verlangt. Die Beschaffenheit der gelieferten Coils haben Fertigungstoleranzen und auch die Walzstrasse selbst hat Materialeigenschaften, die es zu berücksichtigen gilt. Es kann eben nicht alles simuliert werden. Wenn der Zug oder der Schub nicht abgestimmt ist, reisst das Blech mit einem ohrenbetäubenden Knall und der Produktionsprozess steht still. Leiser, aber mit einem ebenso grossen Business Impact steht die Software-Entwicklung still, wenn zu sehr geschoben und zu viel gezogen wird.

Daraus lassen sich folgende Erkenntnisse herleiten:

• Erwartungshaltung und Verfügbarkeit der Ergebnisse müssen bezüglich Umsetzungsgeschwindigkeit im Einklang stehen. Sonst knallt es im Produktionsprozess.
• Qualitätskontrolle ist ein Service an den Produktionsprozess, der permanent und, entsprechend der Produktionsgeschwindigkeit, automatisiert stattfinden sollte.

Sicherlich gibt es noch wesentlich mehr Erkenntnisse aus dem oben genannten Beispiel. Für die weitere Diskussion konzentrieren wir uns auf die beiden oben genannten Punkte. Der erste Teil bezieht sich auf die Umsetzung oder Realisierung von Requirements. Der zweite Punkt bezieht sich auf die Rolle des Testings innerhalb des Sprints. Studien und eigene Erfahrungen belegen, dass sich nach der Änderung der bestehenden Software immer wieder Fehler einschleichen, die vorher erfolgreich eliminiert worden sind. Dies hat vielschichtige Gründe. Zum einen kann das Problem durch eine Fehlsteuerung im Build-Prozess auftreten. Zum anderen kann auch die Versionierung der zuvor durchgeführten Änderungen im falschen Branch stecken geblieben sein.  Mangelndes Wissen oder die damit verbundene Fehleinschätzung einer geplanten Änderung kann ebenfalls eine Fehlerquelle darstellen. Auch sollte an dieser Stelle nicht vergessen werden, dass die Software-Entwicklung seit jeher der Herausforderung unterliegt, mit fehlerhafter Software fehlerfreie Software zu erstellen.

Hinzu kommt, dass in Zeiten von Continuous Integration und Continuous Development (CI/CD), gepaart mit agilen Methoden und Sprints von zwei bis vier Wochen, die Automatisierung von Tests zu einem der wesentlichen Erfolgsfaktoren für den gesamten Entwicklungsprozess wird. Bekanntlich führen mehrere Wege nach Rom. Im zweiten Teil dieses Beitrags wird eine mögliche Lösung der in diesem Beitrag geschilderten Herausforderungen skizziert.