Automatisch testbaren Quellcode erstellen
Trotz intensiver IT- und Fachbereichstests wird viel Quellcode produktiv gesetzt, der sofort im ersten Live Szenario in die Brüche geht. Schlimmstenfalls werden noch andere abhängige Anwendungen mit in die Versenkung gezogen und zwanzig Minuten nach Go-Live liegt die Prio-Störung auf dem Tisch. Wie konnte das nur passieren?
Warum sollten Sie automatisch testbaren Quellcode erstellen?
Das größte Problem ist der mangelnde Überblick über alle Anwendungen die durch eine Änderung betroffenen sein könnten und die Auswirkungen.
Insbesondere “historisch gewachsene Anwendungen” reagieren sehr empfindlich auf kleine Änderungen, insbesondere wenn diese im Laufe der Zeit tief mit anderen Anwendungen verwachsen sind.
Weder die IT, noch ein Fachbereich können 100% aller möglichen Testfälle abdecken. Stattdessen wird meistens die Strategie: “Exploratory Testing” gewählt – sprich wir drücken alle Knöpfe einmal durch und schauen ob genau der eine fehlerfreie Optimalfall funktioniert. Doch es geht auch anders.
Automatischer Regressionstest
Richtig gelesen, es ist möglich den gesamten Regressionstest in einem einzigen Klick abzuarbeiten. Die eierlegende Wollmilchsau also.
Gut, ein wenig Mehraufwand wird nötig sein, schließlich muss ich die Testfälle im Vorfeld einmal definieren.
Das ist im Vergleich zu der technischen Sicherheit, dass eine Änderung die Funktionalität einer Anwendung nicht geändert hat, ein kleiner Preis.
Desweiteren ist das händische testen nach jeder Änderung nicht nur unvollständig, sondern auch eine zeit- und dementsprechend geldaufwändige Angelegenheit.
Test Driven Development
An dieser Stelle möchte ich auch auf die Möglichkeit Hinweisen die Testfälle vor der eigentlichen Entwicklung zu erstellen.
Es muss bekannt sein, was das genaue Input ist und was das erwartete Ergebnis. Darauf basierend kann solange an einzelnen Funktionen gebastelt werden bis diese die Testfälle überstehen.
Das entspricht einer Digitalisierung von den häufig im Fachkonzept textuell beschriebenen Zielen. Diese in konkrete Testfälle umzumünzen ist meist bereits die halbe Miete. Die Erstellung von diesen Testfällen und die Implementierung lässt sich natürlich auch auf verschiedene Personen aufteilen.
Das Ziel des Implementierenden sollte es sein, die Testfälle mit einem möglichst schlanken einfachen Coding zu bedienen. Der Fachbereich und der Testersteller sorgen für die Vollständigkeit der Anforderungen. Im Anschluss beim Regressionstest verhält sich das Coding dann direkt wie angefordert und kann natürlich genauso wie auf normalem Wege programmierter Quellcode automatisch getestet werden. Die Zeit die hier am Anfang zusätzlich benötigt wird um die Testfälle zu erstellen, wird dann wieder eingespart, wenn nach Fertigstellung des Quellcodes sofort ein fehlerfreies Produkt bereit steht.
Was muss ich tun um automatisch zu testen
Die Antwort ist leichter gesagt als getan: Refaktoring und Redesign.
Bestehender Quellcode muss ergänzt werden, neuer Quellcode direkt nach einem neuen Paradigma programmiert werden.
Es muss eine lokale Testklasse angelegt werden, welche wiederum die einzelnen Funktionen abtestet. Das ist kein Hexenwerk und wird in den Jeweils wöchentlich folgenden Blogbeiträgen erklärt.
Save as PDF
