Einführung testgetriebener Entwicklung

Situation

Das Team des Kunden ist mit der Wartung eines großen und auf dem Markt etablierten Software-Produktes betraut. Zu den Aufgaben gehört neben dem Beheben von Fehlern auch die Weiterentwicklung des Produktes um neue Features nach Kundenwünschen. 

Die über viele Jahre gewachsene Code-Basis verwendet unterschiedlichste Technologien und weist in weiten Teilen eine monolithische Architektur auf. Die vorhandenen Tests bestehen zum größten Teil aus manuell durchzuführenden Systemtests. Automatische Unit- bzw. Integrationstests existieren nur vereinzelt.

In der vorhandenen Struktur ist der Aufwand für geplante Änderungen nur schwer einzuschätzen. Zudem sind auch ungewollte Seiteneffekte kaum abzusehen. Regelmäßig kommt es daher zu Regressionen, die erst spät im Entwicklungsprozess entdeckt werden, was wiederum zu Verschiebungen von Releases führt.

Mittelfristig soll die Qualität und damit die Wartbarkeit des Produktes deutlich erhöht werden, um die Release-Zyklen zu verkürzen und die Planbarkeit zu erhöhen. Die dazu notwendigen Refaktorisierungen können effektiv und effizient nur mit einem vorhandenen Sicherheitsnetz von automatisierten Tests auf verschiedenen Ebenen durchgeführt werden. Der hohe Aufwand für manuelle Systemtests soll durch mehr automatisierte Unit- und Integrationstests deutlich verringert werden.

Dauer des Projektes

3 Monate

Lösung

Um die Ziele zu erreichen, musste in den Teams des Kunden entsprechendes Know-how hinsichtlich Testgetriebener Entwicklung (TDD) aufgebaut werden. Sowohl manuelle Tester als auch klassische Entwickler sollten zu Test-Entwicklern ausgebildet werden. Erfahrungsgemäß reicht allein der Besuch einer Schulung zu diesem Thema nicht aus, um einen nachhaltigen Wandel in den Entwicklungspraktiken herbeizuführen. Insbesondere in Brownfield-Projekten wie diesem erfordert der Einsatz von Testgetriebener Entwicklung von den Team-Mitgliedern ein hohes Skill-Set, aber auch Disziplin und das richtige Augenmaß. Gemeinsam mit dem Kunden wählte Method Park daher folgenden Ansatz:

1. Analyse

Auf Basis von Interviews und Reviews wurde die Ist-Situation analysiert: Wie sind die Scrum-Teams strukturiert und über welche Skills verfügen die Mitarbeiter? Wie funktioniert der gelebte Entwicklungsprozess und welche Entwicklungspraktiken insbesondere im Hinblick auf das Testen sind etabliert? Welche Technologien, Programmiersprachen, Frameworks und Werkzeuge sind bereits im Einsatz oder geplant? Wie ist die Qualität der Architektur und des Quellcodes zu bewerten? 

2. Anpassung der Trainingsinhalte

Auf Basis der Ergebnisse der Analyse-Phase wurden die Inhalte der durchzuführenden Trainings bzw. Workshops angepasst. Die Inhalte und die praktischen Übungen wurden abhängig von den Vorkenntnissen der Teilnehmer und den einzusetzenden Programmiersprachen, Technologien und Frameworks erstellt. Ziel war es, in zwei Tagen mindestens folgende Themen abzudecken: 

Einführung in das Testen und in die zu benutzenden Werkzeuge

TDD, BDD, ATDD

Test Doubles und Mocks

Testen von Legacy Code

Testabdeckung

Clean Code

Dependency Injection 

Refaktorisierungen

Golden Master

Abschließend wurde die Workshop-Agenda mit dem Auftraggeber abgestimmt.

3. Durchführung der Hands-on Workshops

Pro Scrum-Team wurde ein Training in Form eines Hands-on Workshops durchgeführt. Um einen hohen Trainingsnutzen zu gewährleisten, begleiteten zwei Method Park Trainer maximal zwölf Teilnehmer. Die Trainer waren Senior Software Engineers mit langjähriger, praktischer Erfahrung in agilen Entwicklungsteams und in den entsprechenden Technologien. Nach kurzen, theoretischen Einführungen bearbeiteten die Teilnehmer zusammen mit den Trainern konkrete Aufgaben und Probleme möglichst nah am realen Projekt.

4. Begleitung der Teams im Projekt

In den auf die Workshops folgenden Sprints sollten die Teams die gelernten Inhalte in der realen Projektwelt anwenden. Erfahrungsgemäß gelingt dies auf Anhieb nicht oder nur schwer. Um die Transition hin zur testgetriebenen Entwicklung sicherzustellen, begleitete ein Trainer ein Team jeweils eine Woche im Projektalltag. Dadurch erhielten die Entwickler und Tester die Möglichkeit etwa im Rahmen von Pair Programming oder gemeinsamen Reviews ihre konkreten Probleme zu lösen.

5. Sprechstunden

In den folgenden Sprints standen die Trainer den Teams in reduziertem Umfang und punktuell zur Verfügung. Telefonisch oder online konnten die Mitarbeiter Fragen oder Probleme mit den Experten von Method Park diskutieren.

6. Abschluss

Mit einem zeitlichen Abstand von etwa sechs Monaten wurde eine abschließende Retrospektive durchgeführt, in der die Fortschritte und die Wirksamkeit der Maßnahmen bewertet wurden.

Weitere Informationen

Software Engineering

Agile Transformation

Ergebnis

Erfolgreiche Einführung von TDD in allen Teams

Messbar bessere Abdeckung durch automatisierte Tests

Deutlich niedrigere Fehlerrate

Weniger Abhängigkeiten und sauberere Interfaces 

Grundlage für sichere Refaktorisierung

Agilere Teams durch engere Zusammenarbeit zwischen Entwicklung und Test