Einleitung
Im agilen Umfeld tragen Regressionstests dazu bei, die Qualität aufrecht zu erhalten. Mit jeder User Story kommen neu entwickelte Funktionalitäten hinzu, alte Funktionalitäten müssen weiterhin funktionieren. Spätestens nach zehn Sprints ist der Regressionsaufwand so hoch geworden, dass man mit manuellen Tests nicht mehr alles nachtesten kann. Also bleibt nur eines: Testautomatisierung.
Ein Projekt, das auf der grünen Wiese entsteht, ermöglicht es, von Anfang an die Testautomatisierung sauber zu integrieren. Gleichzeitig findet man sich im Testumfeld oft als Einzelkämpfer mehreren Entwicklern gegenüber. Wie lässt sich also eine zeitintensive Automatisierung der Funktionalitäten im alltäglichen Doing eines Test Analysten realisieren?
Umfeld in unserem Projekt
In unserem Projekt erstellen wir eine neue Software im JavaScript-Umfeld. Umgesetzt wird diese mit dem Electron Framework. Für die Automatisierung von Testfällen ist dadurch Spectron als Mittel der Wahl gesetzt. Als Projektplattform wird Jira genutzt und das Projekt wird nach dem SCRUM-Modell durchgeführt. Das Projektteam besteht aus (bezogen auf Vollzeit-Tätigkeit):
- 6 Entwicklern inkl. 1 Architekt
- 1 Scrum Master
- 1 Business Analyst
- 1 ½ Testern
Ansatz
Bereits zum Kick-off des Projektes war absehbar, dass die Testautomatisierung durch die Tester nicht geleistet werden kann. Daher hat sich das Team folgende Lösung überlegt:
- die Testautomatisierung erfolgt durch die Entwickler
- der Review für die Testfälle erfolgt durch die Tester
- die Erstellung und die Abnahme der Spectron-Testfälle wird in der Definition of Done festgeschrieben
Vorteile
- Zeiteinsparung Test: Der eigentliche Grund für dieses Vorgehen ist die Ressourcenknappheit seitens der Tester. Hätten diese auch die Automatisierung übernehmen müssen, wäre das Ganze nicht möglich gewesen.
- Perspektivwechsel Test: Die Tester können im Gespräch und im Review einiges lernen. So wird bei Fragen, warum ein Test so geschrieben wurde, die Umsetzung verständlicher. Dadurch entstehen auch Testfälle, an die man sonst nicht gedacht hätte.
- Know-how-Entwicklung: Da es zum Alltag des Programmierers dazugehört, entwicklungsbegleitende Tests zu schreiben, ist das Grundverständnis für die Erstellung der automatisierten Tests sehr hoch. Bei unserem Projekt ist dies bereits mehrfach von Nutzen gewesen:
- Teile der Anwendung konnten mit technischen Kniffen abgedeckt werden, die ein Tester nicht ohne Weiteres hätte liefern können. Ein Beispiel hierfür ist die automatisierte Prüfung der korrekten Darstellung einer Punktewolke in einem Chart und die Anzeige der Details eines gewählten Punktes.
- Über technische Refinements konnten die Performanz und die Stabilität der Spectron-Tests deutlich verbessert werden.
- Nach veränderter Toolauswahl dauerte die Ausführung eines kompletten Spectron-Durchlaufes eine halbe Stunde weniger (25% Zeiteinsparung).
- Perspektivwechsel Entwicklung: Dadurch, dass der Entwickler sich mit der Sichtweise eines Nutzers auf die Funktionalität und die Oberfläche der Software beschäftigt hat, konnte eine Vielzahl von Fehlern vermieden werden und das Grundverständnis stieg durch den regen Austausch mit den Testern.
Nachteile
- Erhöhter Zeitaufwand Entwickler: Was an einer Stelle an Zeit eingespart wird, wird an anderer Stelle wieder benötigt. Der Aufwand kann aber in diesem Fall auf mehrere Schultern verteilt werden.
- Gliederung: Entwickler gliedern Testfälle in technisch logische Bereiche. Da dies nicht immer identisch zur fachlichen Logik ist, kann es für die Tester schwer werden, bestimmte Testfälle wiederzufinden und zu überprüfen.
Herausforderungen und Lösungen
- Traceability DEV-QA: Der Review findet im Projekt im git (Diff-Tool) statt. Im Projekt wurden angepasste und angelegte Spectron-Testfälle durch das Test-Team gereviewed, gelöschte Testfälle aber nicht – in der Annahme, dass diese bei der Anpassung ersetzt wurden. Dadurch waren Requirements nicht mehr abgedeckt.
Lösung: Um den Problemen im Review entgegenzutreten, ist ein Training für den Umgang mit git für alle, die im git arbeiten und reviewen müssen, besonders hilfreich. Auch ein Walkthrough zwischen Test- und Entwicklungsteam bei großen Anpassungen bring einen Mehrwert, damit die Tester besser verstehen, was die Entwickler umgesetzt haben.
- Traceability-Spectron-Anforderungen: Diese Herausforderung ist speziell in unserem Projektumfeld entstanden. Das agile Team verwendet für das Anforderungs- und Testmanagement Jira, während im Umfeld des Kunden aus rechtlichen Gründen die Anforderungen und Testfälle in einer separaten Anforderungsmanagementsoftware spezifiziert werden müssen. Da die Systeme sich nicht kennen, ist eine automatische Traceability nicht gewährleistet.
Lösung: Um dieser Hürde entgegenzuwirken wurde eine direkte Zuweisung der Req-ID in die Spectron Cluster eingeführt.
Fazit
Abschließend lässt sich sagen, dass sich in unserem Projekt der Ansatz bewährt hat, den Test Analysten automatisierte Testfälle nur reviewen zu lassen, statt sie selbst zu schreiben. Die Aufgabenteilung zwischen Testern und Entwicklern fügt sich sehr gut in die agile Vorgehensweise (Scrum) ein. Die Vorteile überwiegen die Nachteile somit bei Weitem.
Dieser Ansatz ist sehr gut geeignet für ein agiles Projekt mit schmalem Staffing und hohem Qualitätsanspruch, das auf der grünen Wiese startet. Man sollte diesen Ansatz aber von Beginn an verfolgen. Ein nachträgliches Aufsetzen ist kaum noch möglich, da eine sukzessive Erweiterung der Testfälle nach jeder User Story deutlich übersichtlicher und einfacher ist als Testfälle en bloc zu erstellen. Des Weiteren werden bereits zu Beginn Entscheidungen in der Umsetzung, der Gliederung, der Architektur und vor allem in den Prozessen (Definition of Done, …) getroffen.
Dieser Beitrag wurde verfasst von:
