Tests sind in der Softwareentwicklung unumgänglich. Doch welche Möglichkeiten gibt es, die Testphase ins Projekt einzubinden – oder spart ganz auf Test zu verzichten Ende doch am meisten Zeit?
Quality Assurance im klassischen Wasserfall-Modell
Als ich nach meinem Studium angefangen habe, zu arbeiten, wurde die Rolle Tester nicht gerade als Traumrolle im Projekt bezeichnet – trotzdem habe ich sie übernommen. In dem Projekt, in dem ich mitarbeitete waren mehrere Teams (insgesamt über 100 Personen) von unterschiedlichen Lieferanten für einzelne Module – Datenbank, Business Logik, Workflow Engine, usw. – verantwortlich.
An meinem ersten Arbeitstag habe ich eine kurze Einarbeitung zum Thema „Testen“ erhalten: Es gab eine Web-Oberfläche, über die ich eine XML-Nachricht an einen Service schicken musste. Daraufhin wurde eine Exception ausgeworfen, die per Mail (Bugzilla war noch nicht vorhanden bzw. wurde nicht benutzt) an einen Architekten und Leiter eines Entwicklungsteams geschickt wurde. Mir war allerdings absolut nicht klar, was durch das Verschicken dieser XML-Nachricht überhaupt passierte. Was testete ich eigentlich?
Das Projekt, in dem ich arbeitete, folgte dem klassischen Wasserfall-Modell. Zu Beginn des Projektes wurde nichts automatisiert. Die meistens Tests wurden wiederholt, sobald ein neuer Fix geliefert wurde. Durch die Fixes tauchten jedoch zum Teil neue Fehler auf. Die Quality Assurance-Phase war demzufolge nicht fest planbar.
Die Phasen in einem klassischen Projekt sehen wie folgt aus:
Wie auch in “meinem” Projekt findet die Testphase erst nach der Entwicklung statt. In dieser hat das Testteam in erster Linie die Aufgabe, alle Fehler – so genannte Bugs – im System zu identifizieren.
Allein hier hat man laut der IBM Sciences Systems Institute ungefähr den dreifachen Aufwand im Vergleich zur Entwicklungsphase. Liegen gravierende Fehler – sogenannte Blocker Bugs – vor, muss man sogar davon ausgehen, dass die gesamte Testphase nach deren Fix erneut gestartet wird.
Je später ein Bug in der Softwareentwicklung entdeckt wird, desto höher sind die Kosten – und die Wahrscheinlichkeit, dass das Projekt scheitert.
Quality Assurance in agilen Projekten
Die meiste Zeit verbrachte ich als Tester also damit, Bugs zu finden, diese zurückzumelden und auf eine Rückmeldung zu warten – um erneut testen zu können, ohne zu verstehen, was ich eigentlich testete. Da mich dieser Ablauf nicht zufrieden stellte, änderte ich meine Vorgehensweise.
Nachdem ich einen Bug gefunden hatte, begab ich mich direkt auf die Entwicklungsebene und übernahm die Analyse der Fehlerursache selbst. Erst danach gab ich meine Ergebnisse an die Kollegen im Workflow-Management- oder Entwicklungsteam weiter. Fixes wurden entsprechend viel schneller geliefert, da die Entwickler sich nicht erst mit der Analyse auseinandersetzen mussten.
Ohne es zu wissen, hatte ich den Weg Richtung Agilität eingeschlagen. Der Fokus in der agilen Softwareentwicklung liegt unter anderem auf der Qualität des Systems. Das Manifesto für Software-Craftmanship geht dabei noch einen Schritt weiter als das Manifest für agile Software-Entwicklung und besagt:
Not only working software, but also well-crafted software
Kein Wunder, dass sich die Phasen eines agilen von denen eines klassischen Software-Projektes unterscheiden:
Die Quality-Assurance-Phase wird wie in klassischen Projekten nach der Entwicklung geplant, allerdings werden die Quality Engineers (Tester) bereits in den früheren Phasen mit einbezogen. Während der Planning-Phase setzen sie sich mit den einzelnen Fachbereichen zusammen und definieren Akzeptanzkriterien, anhand derer später getestet werden kann.
Während der Entwicklung sind sie ein Teil des Entwicklungsteams. Das Entwicklungsteam schreibt so viele Unit (Komponenten-) Tests wie möglich, um die vorab gemeinsam definierten Akzeptanzkriterien zu prüfen. Diese Unit Tests sind zeitsparend und liefern schnelle Ergebnisse.
Dadurch, dass die Quality Engineers bereits während der Entwicklungsphase eingebunden sind, bringen sie das erforderliche technische Know-How mit. Dieses Know-How ermöglicht es ihnen festzustellen, welcher Fachlichkeit bereits über die Unit Tests geprüft wurde.
Die Fachlogik, die durch Unit Tests bereits abgedeckt ist, muss nicht auch über Integrationstests oder sogar über UI Tests erneut geprüft werden. Dies lässt sich nur gut vermeiden, wenn die Quality Engineers die bereits realisierten Tests verstehen und darauf aufbauend die weiteren Testfälle automatisieren.
Weitere End-To-End Tests – die ggf. sehr zeitaufwendig sind und dazu neigen sehr fragile zu sein – werden dann in die Quality-Assurance-Phase automatisiert oder falls nicht automatisierbar, manuell durchgeführt. Die nicht-automatisierbaren Tests sollten einem Testkatalog hinzugefügt werden, so dass diese bei jedem Release sorgfältig durchgeführt werden können.
Bestimmte Tests, z.B. nicht-funktionale Tests, können am besten nur in einer produktionsreife Umgebung durchgeführt werden. Auch hier gibt es die Möglichkeit diese zu automatisieren.
Mit diesem Vorgehen lässt sich die Testphase gut einplanen. Die Risiken, dass die Planung nicht passt, lassen sich dadurch vermeiden, dass zum einen die Testdurchführung bereits in frühen Phasen des Projektes stattfindet und zum anderen schnelles Feedback aufgrund von agilem Vorgehen ermöglicht wird.
Vielleicht sparen keine Tests doch am meisten Zeit?
Das regelmäßige Testen in agilen Software-Projekten mag auf den ersten Blick aufwändig und zeitfressend erscheinen – die Versuchung, die Test doch halbherzig ans Ende des Projektes zu verbannen, ist entsprechend hoch. Wie Robert C. Martin schon sagte: „Anybody who thinks they can go faster by not writing tests is smoking some pretty serious shit.“
Die Illusion, dass man Zeit spart, in dem man keine Tests schreibt, holt einen also sehr schnell ein – kostet es doch weit mehr Zeit, Fehler, die frühzeitig entdeckt hätten werden können, wieder auszubügeln.
Du willst mehr zum Thema Testen in der Softwareentwicklung erfahren? Dann schau dich weiter in unserem Blog um und informiere dich zum Beispiel über das Prinzip der testgetriebenen Softwareentwicklung.
Kommentare