Scrum-Teams haben oft einen sehr genauen Sprintfokus sowie Sprintziel. Dabei wird die Software immer größer und das Sicherstellen der Qualität (auch der bestehenden Funktionen) immer aufwendiger. Ein heute häufig genutzter Lösungsweg führt über Microservices - also Bausteine neuer Sprints innerhalb eines neues Microservices auszuliefern, um den schon laufenden Microservice nicht erneut auf die Qualität testen zu müssen, da keine Abhängigkeiten zu den neuen Bausteinen bestehen. Gibt es aus Eurer Sicht noch weitere Lösungswege, um den Testaufwand während eines längeren Projektes (plus 20 Sprints) gering zu halten und sich als Scrum Team auf die neuen Bausteine neuer Sprints konzentrieren zu können?
2 Antworten
Ich kenne das Problem. Die Software wird immer umfangreicher und die Seiteneffekte durch Neuentwicklungen werden immer unbeherrschbarer. Es gibt dazu ein Grundprinzip: Testautomatisierung! Mein früherer Arbeitgeber, die andrena objects AG hatte sehr gute Kenntnisse im SW-Engineering. Sie haben den Ausdruck geprägt: "Legacy Software ist jede Software, die nicht automatisiert getestet wird." Oder: "Nur Test- und Deploymentautomatisierung ermöglicht wirksame Agilität." Deshalb hatten sie in SW-Projekten zunächst eine Priorität darauf, dass der bestehende Code erstmal mit automatisierten Tests abgesichert wird.
Microservices sind ein gutes Pattern, um Unabhängigkeit zwischen einzelnen Softwarekomponenten zu erreichen. Das alleine reicht aber nicht. Auch die Microservices müssen automatisiert getestet werden. Ich kenne den Kontext nicht, aus dem die Frage entstanden ist. Auf alle Fälle kann ich empfehlen, genau hinzusehen, wie es mit er bestehenden Testautomatisierung aussieht? Ist die Testpyramide erfolgreich umgesetzt?
Also
- automatische Unit-Tests für die Tests direkt im Compiler bzw. der Dev-Umgebung, die nach jedem Checkin ins Code-Repository automatisch ausgeführt werden. (Laufzeit im Bereich von Sekunden bis Minuten)
- Unit- und Integrationtesting auf der (den) Testumgebung(en), die bei jedem Deployment getriggert werden. (Laufzeit im Bereich von Minuten bis Stunden, besser Minuten)
- Smoketests bevor die neuen Funktionen produktiv gehen?
Tests müssen kontinuierlich durchgeführt werden. Wobei anzumerken ist, dass die Tests im Vorfeld vor der Entwicklung definiert werden sollten (Stichwort TDD), damit während der Entwicklung zu jeder Zeit gegen diese Testkriterien getestet werden kann und nicht erst beim Deployment auf die Testumgebung festgestellt wird, dass die Tests nicht erfolgreich laufen. Denn dann fängt man wieder von vorne an und das kostet unnötig Zeit und Geld. Ein oft beobachtetes Phänomen ist das des Mini-Wasserfalls innerhalb eines Sprints. Es ist und war nie Ziel, am Ende eines Sprints festzustellen, dass die Qualität nicht stimmt. Qualität kann nicht eingetestet werden, sondern muss von vorne herein eingebaut werden! Deshalb gelingt es einem guten Scrum-Team, die Tests bereits sehr früh im Sprint zur Verfügung zu stellen.
Hinsichtlich des Testaufwandes bleibt somit festzuhalten, dass der Aufwand idealerweise nur 1x nötig ist, nämlich zum Erstellen der automatisierten Tests. Anschließend sorgt das automatisierte Testsystem dafür, dass die Kosten für das Testen minimal bleiben.
Ich habe Systeme gesehen, wo bei jedem Deployment auf die Integrationsumgebung an die 7000 Tests ausgeführt werden. Das sollte für eine state-of-the-art Testautomation kein Problem darstellen.
Eine weitere Möglichkeit, Testautomatisierung einfacher zu gestalten, ist die Anwendung geeigneter Containerisierung (Stichwort docker) und adhoc Erstellung von Testumgebungen (Stichwort kubernetes). Damit können ganz gezielt Testkonfigurationen hergestellt werden, um in ihnen besondere Testszenarien zu testen. Z.B. können gezielt Netzwerkverbindungen gekappt werden oder falsche Daten erzeugt werden, damit die Tests prüfen können, wie die Software mit solchen Fehlern zurecht kommt.
Wendet man diese Prinzipien konsequent von Anfang an an, lassen sich Software-Systeme damit auch über Jahre hinweg nachhaltig und mit wenig Wartungsaufwand weiterentwickeln. Wurde diesem wichtigen Punkt der Testautomatisierung zu Beginn zugunsten von schnellerer Featureentwicklung zu wenig Aufmerksamkeit gewidmet, bleibt leider nur zu sagen, dass dies nun aufwändig nachgeholt werden muss.
Eine Anmerkung möchte ich noch mitgeben hinsichtlich der Aussage '... Testaufwand gering zu halten, damit sich ein Scrumteam auf die neuen Bausteine neuer Sprints konzentrieren kann...' : Ein Scrum-Team ist vollverantwortlich dafür zu sorgen, dass der Testaufwand eben NICHT aus dem Ruder läuft. Deshalb gehört beim Nachdenken darüber, wie neue Features entwickelt werden zwangsläufig dazu, darüber nachzudenken, wie die neuen Features entsprechend abgesichert werden können, damit man sich über mögliche Seiteneffekte späterer Entwicklungen keine Gedanken machen muss. Es ist also kein entweder-oder, sondern diese Dinge gehören schlicht zusammen.
Abseits der Testautomatisierung und Microservices gibt es natürlich weitere Möglichkeiten, wie nachhaltige Software entwickelt werden kann. Jedem Entwickler müssen die Clean-Code-Prinzipien nicht nur vertraut sein, sondern er sollte sie auch sicher anwenden können. Wenn Microservices auf der modularen Ebene für Unabhängigkeit sorgen, dann gibt es ähnlich wirksame Prinzipien und Software Design Patterns auch auf der Code-Ebene. Z.B. das Single-Responsibility-Prinzip für Klassen. Nähere Infos hierzu finden sich hier: https://clean-code-developer.de/
Ist hier noch Entwicklungspotential der Mitarbeiter gegeben, ist es Aufgabe des Managements, für diese Entwicklung der persönlichen Fähigkeiten entsprechenden Freiraum zur Verfügung zu stellen. Der Invest zahlt sich schon nach kurzer Zeit aus.
Übrigens: Studien haben gemessen, dass das Verhältnis zwischem einem echten Profi-Programmierer und einem durchschnittlichem Programmierer einen Produktivitätsfaktor von bis zu 300, also 30000% ausmachen kann. Es lohnt sich also, bei der Rekrutierung genau hinzusehen. Lieber etwas mehr für einen Profi-Programmierer ausgeben, der vielleicht 30% teurer sein mag wie ein Durchschnittsprogrammierer. Es lohnt sich in den meisten Fällen.
Da fällt mir zum Thema TDD auch noch das ATDD ein, also Acceptance-Test-Driven-Development. Hiermit ist gemeint, dass man die Akzeptanzkriterien nach einem automatisierbaren Pattern definiert. Das gängigste ist: GIVEN [Situation] WHEN [Aktion] THEN [Result]. Z.B. GIVEN the user is logged in, but was inactive for 5 minutes WHEN the webpage is reloaded THEN the user is shown that he was automatically disconnected and prompted to login in again.
Die Anwendung eines solchen Patterns erlaubt es automatisierte Codefragmente und Testklassen erstellen zu lassen, die automatisch dem Testsystem hinzugefügt und sofort zur Ausführung bereit stehen. Der Programmierer muss dann nur noch die leeren Codefragmenthüllen mit den entsprechendem Testcode befüllen.
Dadurch können die Aufwände zur Erstellung und Einbindung der Testszenarien nicht nur reduziert werden, sondern aus der User Story heraus kann sofort eingesehen werden, welche Testszenarien hinterlegt sind. Hiermit ist eine direkte Verknüpfung zwischen Akzeptanzkriterien und Testcode gegeben.
Sehr nützlicher Nebeneffekt: Eine konsequente Anwendung dieser Herangehensweise schärft und verankert das Bewusstsein, dass Entwicklung und Test nicht zwei getrennte Dinge sind, sondern parallel einhergehen. Außerdem wird die werthaltige Diskussion zw. Product Owner und Entwicklungsteam gefördert. Letzteres macht sich bemerkbar in besserem gemeinsamen Verständnis, was wirklich entwickelt werden soll und minimiert Fehlentwicklungen an der tatsächlichen Anforderung vorbei.
Nähere Infos z.B. hier: https://www.informatik-aktuell.de/entwicklung/methoden/einfuehrung-in-acceptance-test-driven-development-atdd.html#:~:text=Einf%C3%BChrung%20in%20Acceptance%20Test%2DDriven%20Development%20(ATDD)
oder hier ein Vortrag meines Agilluminaten-Kollegen Ralph: https://agilluminaten.de/atdd.pdf
Ein gängiges Framework für ATDD: https://cucumber.io/
oder selbst suchen, wie immer gilt: Google is your friend ;-)
Die Anwendung eines solchen Patterns erlaubt es automatisierte Codefragmente und Testklassen erstellen zu lassen, die automatisch dem Testsystem hinzugefügt und sofort zur Ausführung bereit stehen. Der Programmierer muss dann nur noch die leeren Codefragmenthüllen mit den entsprechendem Testcode befüllen.
Dadurch können die Aufwände zur Erstellung und Einbindung der Testszenarien nicht nur reduziert werden, sondern aus der User Story heraus kann sofort eingesehen werden, welche Testszenarien hinterlegt sind. Hiermit ist eine direkte Verknüpfung zwischen Akzeptanzkriterien und Testcode gegeben.
Sehr nützlicher Nebeneffekt: Eine konsequente Anwendung dieser Herangehensweise schärft und verankert das Bewusstsein, dass Entwicklung und Test nicht zwei getrennte Dinge sind, sondern parallel einhergehen. Außerdem wird die werthaltige Diskussion zw. Product Owner und Entwicklungsteam gefördert. Letzteres macht sich bemerkbar in besserem gemeinsamen Verständnis, was wirklich entwickelt werden soll und minimiert Fehlentwicklungen an der tatsächlichen Anforderung vorbei.
Nähere Infos z.B. hier: https://www.informatik-aktuell.de/entwicklung/methoden/einfuehrung-in-acceptance-test-driven-development-atdd.html#:~:text=Einf%C3%BChrung%20in%20Acceptance%20Test%2DDriven%20Development%20(ATDD)
oder hier ein Vortrag meines Agilluminaten-Kollegen Ralph: https://agilluminaten.de/atdd.pdf
Ein gängiges Framework für ATDD: https://cucumber.io/
oder selbst suchen, wie immer gilt: Google is your friend ;-)
Hallo Christoph, die eine Lösung ist wie Du vorgeschlagen hast, die Software so zu bauen, dass sie aus kleine abgekapselte Teile besteht die unabhängig von einander weiterentwickelt und getestet werden können. Das ist ein guter Ansatz.
In manchen Fällen gibt es auch die Möglichkeit Frameworks zu verwenden (Open Source oder eben kaufen) die bereits existieren. So kann die Weiterentwicklung und damit auch der Test einiger Komponenten (das was vom Framework abgedeckt wird) outgesourced werden. Man baut dann die Software über diese Frameworks und somit muss sich die eigene Entwicklungsmannschaft nur um die eigene Funktionalität kümmern.
Unabhängig von der technischen Lösung und Architektur, muss man sich auch fragen ob die wachsende Komplexität notwendig ist. Manchmal werden viel zu viele Funktionen implementiert die keiner braucht (es wird auf Verdacht entwickelt / "es könnte ja vielleicht jemand geben der das braucht"), auch das soll vermieden werden. Nicht nur weil der Test zu aufwändig wird, sondern auch weil überladene Applikationen eine schlechte user experience bieten. Funktionen die mal eingebaut wurden aber nicht mehr benötigt werden müssen abgekündigt und entfernt werden. Das gehört auch dazu.
So, und wenn sich die Komplexität nicht vermeiden lässt, dann muss man eben testen. Da hilft nur (auf verschiedene Ebenen) die Tests zu automatisieren. Das ist nicht nur ein Hilfsmittel für wachsende Komplexität und Testaufwand, sondern auch ein Weg um die Feedback-Loops zu verkürzen und damit die Entwicklung des Systems zu beschleunigen. Im Idealfall sollte eine gewisse Testabdeckung von Anfang an gewährleistet werden, es ist aber auch möglich bei legacy Code in kleinen Schritten die Testabdeckung zu verbessern.
Man könnte auch die Durchführung der Tests outsourcen, dafür braucht es extrem gute Dokumentation der Szenarien/Testfälle die zu testen sind. Da würde ich eher den Aufwand direkt in die Testautomatisierung stecken statt Dokumente zu schreiben die anderen sagen was sie testen müssen.
Ich hoffe, das hilft Dir weiter.
In manchen Fällen gibt es auch die Möglichkeit Frameworks zu verwenden (Open Source oder eben kaufen) die bereits existieren. So kann die Weiterentwicklung und damit auch der Test einiger Komponenten (das was vom Framework abgedeckt wird) outgesourced werden. Man baut dann die Software über diese Frameworks und somit muss sich die eigene Entwicklungsmannschaft nur um die eigene Funktionalität kümmern.
Unabhängig von der technischen Lösung und Architektur, muss man sich auch fragen ob die wachsende Komplexität notwendig ist. Manchmal werden viel zu viele Funktionen implementiert die keiner braucht (es wird auf Verdacht entwickelt / "es könnte ja vielleicht jemand geben der das braucht"), auch das soll vermieden werden. Nicht nur weil der Test zu aufwändig wird, sondern auch weil überladene Applikationen eine schlechte user experience bieten. Funktionen die mal eingebaut wurden aber nicht mehr benötigt werden müssen abgekündigt und entfernt werden. Das gehört auch dazu.
So, und wenn sich die Komplexität nicht vermeiden lässt, dann muss man eben testen. Da hilft nur (auf verschiedene Ebenen) die Tests zu automatisieren. Das ist nicht nur ein Hilfsmittel für wachsende Komplexität und Testaufwand, sondern auch ein Weg um die Feedback-Loops zu verkürzen und damit die Entwicklung des Systems zu beschleunigen. Im Idealfall sollte eine gewisse Testabdeckung von Anfang an gewährleistet werden, es ist aber auch möglich bei legacy Code in kleinen Schritten die Testabdeckung zu verbessern.
Man könnte auch die Durchführung der Tests outsourcen, dafür braucht es extrem gute Dokumentation der Szenarien/Testfälle die zu testen sind. Da würde ich eher den Aufwand direkt in die Testautomatisierung stecken statt Dokumente zu schreiben die anderen sagen was sie testen müssen.
Ich hoffe, das hilft Dir weiter.