Oliver HösliOliver Hösli Je agiler das Vorgehen, desto automatisierter das Testen?

26.09.08 by Oliver Hösli

Der Nutzen, der mit automatisiertem Testen über den Lifecycle einer Applikation hinweg geschaffen werden kann, ist unbestritten. Es lässt sich aus einer IT Management-Sicht plausibel aufzeigen, dass sich der zusätzliche Aufwand lohnt.

Nur auf das einzelne Projekt bezogen, bedeutet es, vor allem bei Software, die sich noch stark verändert  nur Mehraufwand. Deshalb scheuen und vermeiden „kurzsichtige“ Projekte allzu oft, die Voraussetzungen für ein automatisiertes Testen parallel zum Projekt zu schaffen. Das IT Management ist gefordert!

Zeitliche Abhängigkeiten

Die Schwierigkeit liegt darin, dass automatisiertes Testen auf „gleicher Höhe“ mit dem Projekt zu halten, um diesen Nutzen wirklich zu realisieren. Da sich Applikationen meist bis zum Projektende stark verändern können, wird dies oft nicht umgesetzt. Die Kunst liegt darin die Parallelität des Entwicklungsprojektes mit dem automatisiertem Testen zu gewährleisten.

Der Entwicklungsansatz macht den Unterschied

Projekte werden je nach Gusto nach verschiedensten Vorgehensweisen abgewickelt. Die einen schwören auf klassische Wasserfallmodelle, andere sehen in agilen Ansätzen wie SCRUM, FDD (Feature Driven Development), RUP (Rational Unified Process) oder XP (Extreme Programming) klare Vorteile. Diesem Umstand muss auch bei der Erstellen und Anpassen von Testvorgaben im Projekt Rechnung getragen werden da die verschiedenen Projektsetups andere Anforderungen an das Testprojekt stellen.

Klassischer Ansatz (Wasserfall)

Da sich während der eigentlichen Entwicklung der funktionale Umfang ändern kann, und die Software sich bis zur Freigabe trotz Wasserfall teilweise sehr stark verändert, ist es nicht einfach automatisierte Tests frühzeitig aufzubauen.

Aus diesem Grund „hinken“ automatische Tests oft dem Projekt hinterher. Sie leisten deswegen Ihren Beitrag erst beim Regression Testing. Hauptziel des automatisierten Testens ist es dann, den funktionalen Umfang der jeweiligen Vorgängerversion automatisch zu testen. Im Projekt sind zwingend die Anpassungen an bestehenden Funktionen im Nachhinein an den Testscripts nachzuvollziehen. Da diese Anpassungen der Testscripts erst in den Folgeversionen zum Tragen kommen, wird dies oft vernachlässigt.

Klare Zielsetzungen, Weisungen und Abnahmen durch das Entwicklungsmanagement sind ein kritische Erfolgsfaktoren für das automatische Testen in einem  solchen Umfeld.

Ablauf automatisiertes Testen beim Wasserfallmodell

Ablauf automatisiertes Testen beim Wasserfallmodell

SCRUM oder andere „Agile Entwicklungsansätze“ wie FDD, RUP, XP

Gerade agile Entwicklungsvorgehen provozieren, dass sich die Software bis kurz vor Freigabe wesentlich ändert. Wird SCRUM angewendet, gilt der Fokus den Sprints.

Zwingend muss sich die Erstellung der Testvorgaben für das automatisierte Testen an den Sprintzyklus der SCRUM-Sprints anpassen. Es entsteht ein eigentlicher Scripting-Zyklus. Der Nutzen tritt noch stärker als bei klassischen Vorgehen zeitlich verschoben  ein, beim nächsten Sprint. Allerdings liegt dieser viel näher und betrifft meist die selben Ressourcen.

Mit einem entsprechenden Scripting-Zyklus können bis zu zu 80% des Codes ab dem zweiten Sprint automatisch getestet werden können!

Wenig Fluktuation in der Teamzusammensetzung über die Sprints hinweg, sowohl in Entwicklung wie auch im Test, ist ein kritischer Erfolgsfaktor für automatisiertes Testen. Damit wird sichergestellt, dass die Teams von der eigenen Vorarbeit profitieren können.

Ablauf automatisiertes Testen bei agilen Entwicklungsvorgehen

Ablauf automatisiertes Testen bei agilen Entwicklungsvorgehen

Fazit

Wegen der kurzen Sprints und der damit verbundenen Motivation an den „Sprint danach“ zu denken, motivieren agile Entwicklungsansätze ein automatisiertes Testen. Das gleiche Sprint-Team kann ihre zuvor erstellten Scripts innerhalb des nächsten Sprints wieder verwenden. Mit einem an die Sprintzyklen angepassten Erstellen und Unterhalten der Testvorgaben, kann schon sehr früh ein hoher Anteil der Applikation automatisiert getestet werden.

Voraussetzung ist, dass in den Sprintsitzungen jeweils der Abgleich mit dem Teil des „Testlabors“ stattfindet, der für die Anpassung der Testvorgaben und Testscripts zuständig ist. Damit kann auf Veränderungen laufend reagiert werden.

Theoretisch könnte der Nutzen von Testautomatisierung bei einem klassischen Entwicklungsvorgehen höher als bei agilen Ansätzen sein, da die Programme sich nach Spezifikationsphase in der Entwicklung viel weniger bewegen. Doch weil der hohe Nutzen der Automatisierung der Tests sich erst nach Abschluss des Projekts einstellt, ist die intrinsische Motivation des Projektteams, Grundlagen zu legen, ohne weitere Management-Massnahmen, limitiert.

Sphere: Related Content

Kommentar schreiben

XHTML: Sie können diese Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>