Entwicklung vom agilen zum Continuous Testing

Bereits seit einigen Jahren steht die agile Transition in vielen Organisationen im Fokus. Doch wie passt solch ein agiler Projektansatz zu den bisherigen oftmals nach dem Wasserfallprinzip organisierten Teststrukturen? Und wie entwickelt sich das agile Testen weiter?

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Zahlreiche Unternehmen definieren ihre Projektprozesse neu, hin zu mehr Agilität. Ziel ist es, bisher komplexe, langwierige Projekte in kleine Softwarepakete zu zerlegen, um schneller und flexibler neue Themen in Produktion bringen zu können. Die kleinen Pakete sollen in kurzen, iterativen Zyklen umgesetzt, getestet und deployed werden.

Kürzere Release-Zyklen stellen das Software-Testing aber zwangsläufig vor neue Herausforderungen. Die Anpassung der Testprozesse ist aufwändiger, als es auf den ersten Blick erscheint. Während in klassischen Projekten oft mehrere Wochen für manuelle Tests im Rahmen einer Testphase eingeplant wurden, ist bei agilen Projekten ein deutliches Umdenken notwendig.

Da nur sehr kurze Zeiträume für Softwaretests zur Verfügung stehen, ist eine enge Zusammenarbeit von Tester und Entwickler in agilen Teams sinnvoll. Testen wird deutlich technischer, da oftmals bereits einzelne Softwarekomponenten mittels Mocking getestet werden müssen, ohne dass die komplette Anwendung zur Verfügung steht.

Um die Qualität der Software-Auslieferung sicherzustellen und Quereffekte zu anderen Systemen auszuschließen, werden zudem laufend Regressionstests benötigt. Durch manuelles Testen ist dieses kaum noch zu bewerkstelligen. Damit nimmt die Bedeutung der Testautomatisierung für agile Projekte stark zu.

Gleichzeitig ändern sich die Anforderungen an die Mitarbeiter, die im Software-Test tätig sind. Während in den klassischen Wasserfall-Projekten die Testmitarbeiter eher fachlich aufgestellt waren, wird künftig vermehrt Entwicklungs-Know-How für die Testautomatisierung und Testdurchführung benötigt. Insbesondere Organisationen, in welchen die Software-Tests bisher fachbereichsnah durchgeführt wurden, werden hier umdenken müssen. Tester und Entwickler müssen sich in agilen Teams abstimmen und zusammenarbeiten, um gemeinsam die Qualität des Release-Kandidaten gewährleisten zu können.

Vom agilen Testen zu Continuous Testing

Die Einführung eines agilen Test- und Projektvorgehens ist der erste Schritt. Von einer Weiterentwicklung der agilen Prozesse hin zum Continuous Delivery spricht man, sobald Organisationen eine automatisierte Deployment-Pipeline aufbauen.

Die Idee dabei ist, dass mit jeder Softwareänderung, die ein Entwickler im Versionskontroll-System (VCS) eincheckt, eine automatische Deployment-Pipeline startet. Im Rahmen dieser Pipeline werden auch verschiedenen Test-Stages durchlaufen. Dabei werden automatische Tests durchgeführt und der Entwickler erhält unmittelbar ein Feedback über die Qualität seiner Softwareänderung. Hier spricht man von „Continuous Testing“.

In der finalen Ausbaustufe durchläuft das Software-Artefakt beim Continuous Testing die unterschiedlichen Test-Stages weitgehend automatisch. Wenn ein Test innerhalb einer Stage fehlschlägt, stoppt der komplette Deployment-Prozess. Damit wird auch klar, dass die Entwicklung stabiler automatisierter Tests ein zentraler Bestandteil jeder Entwicklungs-Task wird.

Ein Feature gilt erst als fertig entwickelt, wenn die dazugehörigen Unit-Tests fertiggestellt sind. Sofern Fehler auftreten, soll der Entwickler möglichst direkt über Dashboards oder E-Mail automatisch informiert werden und diese fixen. Mit dem Commit der Softwareänderung durch den Entwickler startet anschließend der Prozess erneut.

Test-Stages am Beispiel eines Continuous-Testing-Prozesses

In der Abbildung 1 ist ein beispielhafter Continuous-Testing-Prozess dargestellt. Der Prozess startet automatisch mit dem Einchecken einer Änderung mit der Commit-Stage. Hier finden sowohl automatische Code-Reviews sowie Unit-Tests statt. Die Commit-Stage dient dazu, dem Entwickler unmittelbares Feedback über die Qualität seiner eingecheckten Änderung zu liefern.

Üblicherweise läuft eine Commit-Stage nicht länger als fünf Sekunden. Erst wenn die Commit-Stage erfolgreich durchlaufen wurde, wird das Software-Artefakt automatisch auf ein Repository hochgeladen. Aus diesem Repository werden die Software-Änderungen für die folgenden Stages gezogen und automatisch auf den jeweiligen Testumgebungen deployed.

Anschließend folgt die Acceptance-Test-Stage. Hier sollen insbesondere automatische Akzeptanztest und Reggressionstests durchlaufen werden. Eine besondere Herausforderung liegt darin, die automatischen Tests so zu strukturieren, dass der Entwickler auch hier ein schnelles Feedback erhält. So hat es sich bewährt, die automatischen Tests zu clustern: nach Schnellläufern und langsameren Testfällen. Die Cluster von Testfällen laufen anschließend parallel auf verschiedenen virtuellen Testumgebungen.

Damit wird aber auch eine weitere Herausforderung des Continuous Testings deutlich: Die Organisationen benötigen eine Vielzahl von Testumgebungen, welche möglichst Ad-hoc zur Verfügung stehen müssen. Virtuelle Testumgebungen und Mocking von Drittsystemen werden daher deutlich an Bedeutung gewinnen.

Lediglich in der Pre-Production-Stage ist es vorgesehen, dass Testmitarbeiter einige manuelle Akzeptanztests durchführen sowie explorativ die Anwendung testen, um mit letzter Sicherheit Fehler ausschließen zu können. Zudem laufen hier automatische Last- und Performancetests unter möglichst produktionsnahen Bedingungen.

Die Änderungen können dann nach Freigabe direkt in das produktive System eingespielt werden. Einige Unternehmen verzichten bereits komplett auf die Durchführung manueller Testfälle. Doch dieses stellt in der Praxis bislang noch eine Ausnahme dar.

Ist Continuous Testing für jede Organisation sinnvoll?

Generell wird deutlich, dass ein optimaler Continuous-Testing-Prozess einen sehr hohen Grad der Prozessautomatisierung und Testautomatisierung erfordert. Davon sind viele Organisationen aktuell noch weit entfernt.

Zum einen ist der Aufwand für die Testautomatisierung, die Einführung der notwendigen Tools und die Qualifikation der Mitarbeiter nicht unerheblich. Zum anderen existieren in vielen Unternehmen komplexe Abhängigkeiten zu Drittsystemen, die mittels Mocking und Virtualisierung der Umgebungen gelöst werden müssen. Daher kann die Einführung von Continuous Testing nicht über Nacht erfolgen. Vielmehr ist es ein Entwicklungsprozess der Organisation, der in Stufen stattfindet.

So ist es sinnvoll, dass die Organisationen ihre aktuellen Testprozesse bewerten und hinsichtlich des agilen Vorgehens einordnen. Zudem sollte ein Zielbild definiert werden, welches erreicht werden soll. Hierbei ist es sinnvoll, dass erfahrenen Experten diesen Prozess unterstützen. Aus diesen Vorgaben lassen sich dann konkrete Schritte ableiten, die eine Organisation durchführen sollte, um eine nächste höheren Reifegrad in Richtung Continuous Testing zu erreichen.

Dabei ist es nicht für jedes Unternehmen sinnvoll, das Experten-Level anzustreben. Stattdessen gilt zu bewerten, wie viele Softwareprojekte eine Organisation regelmäßig durchführt und wie schnell die Organisation auf Marktveränderungen reagieren möchte. Typischerweise lohnt sich eine vollständige Prozessautomatisierung erst, ab einer hohen Zahl regelmäßiger Software-Releases. Hingegen erscheinen „Einsteiger-Level“ und „Mittleres Level“ auch heute schon für normale mittelständische Unternehmen außerhalb des Technologiesektors erreichbar und sinnvoll.

Zusammenfassung

Um die kurzen Release-Zyklen optimal nutzen zu können, verspüren viele Organisationen den Wunsch nach einer weiteren Automatisierung der Built-, Test- und Release-Prozesse mittels Continuous Delivery. Das Continuous Testing legt hierbei den Fokus auf die Automatisierung der Testprozesse. Dabei lässt sich das Continuous Testing niemals isoliert betrachten, sondern ist immer eng verzahnt mit den Release- und Built-Prozessen der Organisation.

Testautomatisierung, Umgebungsvirtualisierung und Mocking sind beim Continuous Testing von zentraler Bedeutung. Daraus ergeben sich geänderte Anforderungen an die Organisation der Software-Tests, die eingesetzten Tools und an die Qualifikation der im Test tätigen Mitarbeiter. Software-Testing entwickelt sich aufgrund der agilen Transformation künftig vermehrt zu einer technischen Aufgabe.

* Frank Sygusch ist Senior Consultant bei der Management- und IT-Beratung Acando. Er hat langjährige Erfahrungen im Business Consulting und berät Kunden vor allem im Testmanagement und Projektmanagement. Zudem beschäftigt er sich als Leiter der Acando Expert Group für Testmanagement mit der richtigen Ausgestaltung von Testprozessen, aktuell insbesondere hinsichtlich der agilen Herausforderungen für Unternehmen.

Dieser Beitrag stammt von unserem Partnerportal Dev-Insider.de.

(ID:45026487)