Agile Softwareentwicklung …
Agilität hat zu einem neuen Ansatz in der Softwareentwicklung geführt. Der Kunde – und damit die Kundenwünsche – stehen nun wesentlich stärker im Mittelpunkt des Entwicklungsprozesses, als dies bei eher traditionellen Methoden der Fall war – und zum Teil immer noch ist. Der Kunde soll nicht mehr am Ende eines Softwareprojekts ein Resultat „vorgesetzt“ bekommen, welches dann mit großer Wahrscheinlichkeit nicht seinen ursprünglichen Vorstellungen und Wünschen entspricht. Stattdessen wird der Kunde durch die regelmäßige Auslieferung produktiver Software in den Entwicklungsprozess eingebunden. Natürlich bedeutet dies auch neue Verpflichtungen für den Kunden, wie die Teilnahme an regelmäßigen Demos. Dies ist jedoch sehr gut investierte Zeit, die an anderer Stelle auch wieder eingespart werden kann (z.B. bei der Erstellung des Pflichtenheftes). Insbesondere resultiert aus dieser intensiven Kommunikation zwischen dem Kunden und dem Entwicklungsteam ein wesentlich besseres, gemeinsames Verständnis der Fachanforderungen. Der Kunde bekommt so die Möglichkeit Änderungswünsche zu einem frühen Zeitpunkt im Projekt zu erkennen, zu formulieren und auch umgesetzt zu bekommen. Es zeigt sich in der Praxis immer wieder, dass die rein „theoretische Diskussion“ von Anforderungen anhand eines klassischen Pflichtenheftes problembehaftet ist. Mit Hilfe der agilen Entwicklung werden diese Diskussionen verlagert und können zu einem guten Teil viel plastischer anhand bereits realisierter Softwarefunktionen geführt werden. Dies führt zu wesentlich besseren Resultaten, da es hilft die Erwartungen des Kunden zu erkennen und in der Software umzusetzen. Kontinuierlich messbare Größen sind hier die Qualität und die Anzahl der umgesetzten Funktionalitäten. Letzten Endes bedeutet dies auch mehr finanzielle Sicherheit für den Kunden und insgesamt mehr Kundenzufriedenheit.
… erfordert Agiles Testen
Natürlich reicht es nicht aus Kundenwünsche nur frühzeitig zu erkennen, sondern es muss auch darauf reagiert werden und geänderte Anforderungen müssen umgesetzt werden. Die Software ist also wesentlich häufigeren – und evtl. auch tiefgreifenderen – Änderungen unterworfen, als dies bei herkömmlichen Softwareprojekten der Fall ist. Hier kommt der Brückenschlag zum Agilen Testen. Bei agilen Projekten ändert sich die Software in Iterationen (oder sog. Sprints ) und sie ändert sich schnell. Im Normalfall dauert ein Sprint zwei bis drei Wochen und am Ende eines Sprints soll komplett getestete Software stehen, die an den Kunden ausgeliefert und produktiv genutzt werden kann. Das Schreiben von Testplänen und deren manuelle Ausführung mit Hilfe eines Testteams ist somit keine Option mehr, da dieser Ansatz nicht Schritt halten kann mit der geforderten Geschwindigkeit und Flexibilität des agilen Entwicklungsprozesses. Die logische Konsequenz ist die Automatisierung von Tests, um diese möglichst schnell und auch möglichst häufig ausführen zu können. Denn Tests werden nun nicht nur einmal am Ende einer Iteration ausgeführt, sondern im Normalfall mehrmals täglich und von verschiedenen Entwicklern, um Änderungen zu testen bevor diese freigegeben werden (Stichwort Kontinuierliche Integration ). Insbesondere sogenannte Regressiontests garantieren hierbei, dass neue Funktionen nicht bereits bestehende Funktionen beeinträchtigen. Oft werden automatisierte Tests durch so genanntes Exploratives Testen vervollständigt, bei denen im Idealfall mehrere Team-Mitglieder – oder auch andere Personen – die Software „einfach ausprobieren“. (Ganz so einfach ist es natürlich nicht, sondern das Thema exploratives Testen könnte sicherlich einen eigenen Blogbeitrag füllen.)
Mit der Qualität der automatisierten Tests steht und fällt die Qualität der Software. Dies ist vergleichbar mit der Qualität von Testplänen – und deren korrekter Ausführung – bei traditionellen Tests. Die automatisierten Tests müssen vertrauenswürdig sein und daher mit demselben hohen Qualitätsanspruch entwickelt werden, wie die eigentliche Software. Vertrauenswürdig bedeutet hierbei, dass sich ein fehlgeschlagener Test auch wirklich auf ein Problem in der getesteten Software zurückführen lässt und nicht auf einen Fehler in der Implementierung des Tests selber oder der Testumgebung. Man sollte also nicht der Illusion verfallen es würde reichen ein paar Skripte zu schreiben, aber es kann ein Anfang sein. Auch ist der initiale Aufwand für automatisierte Tests höher als bei klassischen Tests und: Dieser Aufwand kann nicht einfach an das Ende des Projekts verschoben werden. Die Entwicklung der Software und der zugehörigen automatisierten Tests muss parallel erfolgen. Wobei dies in der testgetriebenen Entwicklung noch strikter gehandhabt wird. Dort müssen die Tests vor der Software geschrieben werden.
Die Rolle des Software-Testers …
In der agilen Softwareentwicklung existiert die Rolle des klassischen Testers im Prinzip nicht mehr. Dies hat mit den geänderten Anforderungen an diese Rolle zu tun, denn Tests werden nicht länger anhand eines Testplans ausgeführt sondern programmiert. Diese Programmierung kann dabei eine vergleichbare Komplexität aufweisen wie die Implementierung der zu testenden Anwendung. Des Weiteren steht bei der agilen Entwicklung der Teamgedanke im Vordergrund. Diesem Teamgedanken läuft eine strikte Trennung in Entwicklerteams und Testteams entgegen. Im Idealfall sollte jeder Entwickler auch automatisierte Tests schreiben. In der Praxis werden sich jedoch meist einige Entwickler im Team stärker auf diesen Teilaspekt spezialisieren. Dies ist vergleichbar mit anderen Spezialisierungen in der Softwareentwicklung. Es ist jedoch unerlässlich, dass das Schreiben der automatisierten Tests in dem entsprechenden Entwicklungsteam stattfindet und nicht an eine „externe Funktion“ im Unternehmen abgegeben wird. Idealerweise werden die Testfälle zusammen mit Experten aus der Fachabteilung entwickelt. Ein vielversprechender Ansatz ist hierbei das Schreiben sogenannter „Ausführbarer Spezifikationen“. Diese versuchen Spezifikation, Erklärung, Beispiel und Testbeschreibung in einem Dokument zu vereinen. Ein Ansatz den auch die im folgenden vorgestellten Tools auf die eine oder andere Art und Weise verfolgen.
… und Testing-Tools
Natürlich können automatisierte Tests und Testskripte komplett von Hand geschrieben werden. Jedoch gibt es gute Frameworks und Tools, die ein Entwicklungsteam bei der Erstellung solcher Tests unterstützen. Dabei werden Tests häufig mit Hilfe einer benutzerfreundlichen Schnittstelle verfasst und mittels Eingabeparametern und erwarteten Resultaten beschrieben. Um dies zu ermöglichen müssen jedoch zuvor die Testfunktionen implementiert werden, die in der Lage sind diese Parameter für einen Test korrekt zu verarbeiten. Das Robot Framework erwartet Testdefinitionen zum Beispiel in Form von HTML-Tabellen. Testfälle können dabei aus mehreren Schritten zusammengesetzt werden. Nach der Testausführung wird ein HTML-Report erstellt, der die Ergebnisse des Testlaufs aufbereitet. FitNesse ist ein weiteres Test-Tool, welches noch mehr Augenmerk auf das kollaborative Testen setzt. Testfälle sind daher in Form eines Wikis angelegt und können somit sehr einfach im Team bearbeitet werden. Neben den zuvor genannten frei verfügbaren Tools gibt es auch kommerzielle Tools wie zum Beispiel Twist . Dieses unterstützt ebenfalls kollaboratives Testen und bietet Unterstützung, um Testfälle umgangssprachlich zu beschreiben. Der Umfang dieser Tools rechtfertigt im Prinzip jeweils einen eigenen Artikel, zumal auch die Integration weiterer Werkzeuge – abhängig vom Anwendungsfall – betrachtet werden muss. Im Webumfeld könnte dies zum Beispiel Selenium oder Webtest für automatisierte GUI-Tests sein.
Zusammenfassung
Agiles Testen ist das Herzstück agiler Softwareentwicklung. Erst automatisierte Tests ermöglichen kontinuierliche Änderungen an der Software schnell zu testen und garantieren somit gleich bleibende Qualität. Dies ist unabdingbar für den Prozess der kontinuierlichen Integration, welcher wiederum die Grundlage für die iterative Auslieferung produktiver Software ist. Die Rolle des klassischen Softwaretesters verschiebt sich dabei in Richtung Softwareentwickler, da automatisierte Tests ausprogrammiert werden müssen. Auch sollte es in agilen Teams keine explizite Abtrennung dieser Rolle mehr geben. Unterstützt wird das automatisierte Testen durch eine Reihe frei verfügbarer und kommerzieller Tools, die für den eigenen Anwendungsfall evaluiert werden sollten. Natürlich macht es dabei Sinn Kompetenzen für ein Tool (oder einen Satz von Tools) aufzubauen und diese in mehreren Projekten zu nutzen und auszubauen. Vervollständigt werden die automatisierten Tests durch exploratives Testen. Hierbei werden die Funktionen der Software „ausprobiert“ ohne dass man einem strengen vorgegebenen Testplan folgt. Es macht sicherlich Sinn, automatisierte Tests in einem Unternehmen zunächst in einem kleineren Projekt einzuführen, um die Vorgehensweisen dort zu testen und Erfahrungen zu sammeln. Hier können auch ggf. Tools evaluiert werden. Mit den gesammelten Erfahrungen lassen sich automatisierte Tests danach leichter unternehmensweit einführen. Auch wird die Qualität und die erzielte Testabdeckung ständig weiter steigen, wenn die Erfolge und Probleme der agilen Testmethoden als Teil der regelmäßigen Retrospektiven betrachtet werden.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Thomas Jaspers
22.2.2019 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Thomas Jaspers
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.