21. November 2014Tags: Keine Kommentare Simon Krüger

Ein vollständiger und strukturierter Testprozess ist fester Bestandteil jedes modernen Softwareprojekts. Die Testplanung setzt häufig bereits in der Phase der Anforderungsdefinition ein, in der den gestellten Anforderungen direkt passende Testfälle zugeordnet werden.
Bei Software, die sich bereits im Einsatz befindet und häufig seit Jahren kontinuierlich weiterentwickelt wird, fehlt dieser Prozess dagegen meist. Wie lässt sich nun für diese Produkte nachträglich ein Testprozess einführen, damit Erweiterungen und Verbesserungen kontrolliert und mit minimiertem Risiko in die Produktion übergeben werden können?
Insbesondere bei komplexen Systemen mit vielen Spezialfällen kann es ohne einen definierten Testprozess auch lange nach einer Übergabe zu unerwünschtem Verhalten kommen. Denn bei der Übergabe wird nur die neue Funktionalität oder die Korrektur eines bestimmten Fehlverhaltens getestet. Der Aufwand einer Fehlersuche ist allerdings ungemein höher, wenn man nicht weiß, welcher Änderung dieser zuzuordnen ist.

Komplexität

Ein System, das seit 10 Jahren eingesetzt und kontinuierlich weiterentwickelt wird, erreicht im Laufe der Zeit ein Maß an Komplexität, welches verhindert, dass normale Testfallentwurfsverfahren greifen.
Mögliche Schwierigkeiten beinhalten unter anderem mangelnde oder fehlende Dokumentation, komplexe, vielschichtige Abhängigkeiten im Programmablauf oder ein zu großer Umfang der zu testenden Komponenten.

Definition einer Basisversion

Um diesen Schwierigkeiten zu begegnen, ist es essentiell, sich zunächst in Abstimmung mit allen Beteiligten – dem Anwender, dem Kunden, dem Projektmanagement und der Entwicklung – auf einen Entwicklungsstand zu einigen, der die Basis für alle zukünftigen Erweiterungen bildet.
Alle in dieser Version noch vorhandenen Bugs oder Abweichungen vom gewünschten Verhalten müssen festgehalten werden.
Auf diese Basisversion werden nun die üblichen Testfallermittlungsverfahren angewendet. Dabei kommt insbesondere den empirischen Verfahren eine größere Bedeutung zu.
Alle ermittelten Testfälle werden anschließend einmalig mit der Basisversion ausgeführt und definieren auf diese Weise nicht nur den Ist- sondern auch den Sollzustand.

Automatisierung des Tests

Nachdem ein vollständiger Ergebnissatz definiert wurde, sollte die Wiederholung der Testfälle so weit wie möglich automatisiert werden, da diese in Zukunft bei jeder neuen Version komplett wiederholt werden. Eine sinnvolle Lösung ist ein Tool, das den Test startet und einen grafisch aufbereiteten Bericht darüber ausgibt, welche Testfälle noch mit dem erwarteten Ergebnis übereinstimmen und welche abweichen. So müssen nur jene Testfälle manuell überprüft werden, die eine Abweichung aufweisen.

Erweiterung der Testbasis

Für jede weitere Entwicklung des Systems werden nun regulär Testfälle definiert, die sich bei der Testbasis bedienen um die erwarteten Ergebnisse zu bestimmen. Die neuen Testfälle werden dem Testpool der Basisversion hinzugefügt und bei späteren Weiterentwicklungen ebenfalls wiederholt.
Sollte sich durch eine neue Anforderung das Verhalten bezüglich der vorhandenen Testfälle ändern, muss für jede Änderung geprüft werden, ob die Abweichung sich im Ergebnis des Testlaufs korrekt wiederspiegelt. Wenn alle Änderungen überprüft und als korrekt eingestuft wurden, bildet das Ergebnis des Tests das neue Basisergebnis.

Versionsmanagement

Die Testfälle und die zugehörigen Ergebnisse werden an das vorhandene Versionsmanagement angekoppelt, so dass zu jeder Version auch die zugehörigen Testfälle dokumentiert werden. Dabei sollen insbesondere die Abweichungen im Testergebnis nachvollzogen werden können.

Fazit

Die Einrichtung eines praktikablen Regressionstests für bestehende Software ist einmalig mit einem hohen Aufwand verbunden, insbesondere wenn neben der Testfallermittlung auch Aufwand für die Automatisierung entsteht. Die langfristigen Vorteile liegen insbesondere im verringerten Aufwand im Supportbereich, da komplexe Abhängigkeiten von Programmerweiterungen mit hoher Wahrscheinlichkeit in der Testphase entdeckt und zu diesem Zeitpunkt noch leichter nachvollzogen werden können.

Das vorgestellte Verfahren zur Definition eines Testprozesses klingt zunächst sehr umfangreich und gerade die Einführung ist es auch. Es hat sich jedoch gezeigt, dass bei komplexen Systemen insbesondere wenn größere Überarbeitungen anstehen, der Aufwand mehr als gerechtfertigt ist, um folgenschwere Zwischenfälle im produktiven Verhalten zu verhindern und somit das Risiko und die Supportkosten deutlich zu senken.