TESTEN IN AGILEN PROJEKTEN

Agile Softwareprojekte folgen besonderen Methoden, um Software anwenderzentrisch und iterativ zu entwickeln (ein paar Ansichten zu Sinn und Unsinn agiler Methoden: https://agile-ants.de/2019/11/27/alles-agil-oder-was/). Agiles Arbeiten führt zu schnelle Feedbackzyklen zwischen Entwicklungsteam und Product Owner und damit auch zu häufigen Lieferungen neuer Software Artefakte.

Potentiell produktionsreife Software mit jedem Sprint

In Scrum ist das Ziel jedes Sprints die Umsetzung der User Stories, auf die sich das Team zu Beginn des Sprints committed hat. Somit wird zum Ende jedes Sprints ein Stück Software geliefert, das diese neu umgesetzten Funktionalitäten beinhaltet.

Das bedeutet auch, dass dieses Sprint Artefakt einen Qualitätsanspruch haben sollte, der einem produktionsreifen Zustand entspricht (“potentially shippable”). Um dies zu erreichen, muss das Testen der Software fest in der Entwicklung verankert werden und in der Verantwortlichkeit der Entwicklungsteams liegen.

“Shift left” pattern

Je später im Entwicklungsprozess ein Bug gefunden wird, umso mehr Schaden (Kosten, Projektrisiko, Zeitverzögerungen, Verlust an Reputation) entsteht für das Unternehmen. Organisationen sollten also bestrebt sein, Fehler möglichst früh im Entwicklungsprozess zu finden und beheben. Das klingt zunächst logisch. 

Dennoch organisieren viele, auch agile, Projekte ausgerechnet ihre Testphasen nach dem Wasserfallprinzip: Erst wenn alle zu testenden Lösungsbausteine verfügbar sind finden zwei- bis dreimal jährlich groß angelegte Testvorhaben und komplexe Staging-Orgien statt.

Leider macht man auf diese Weise beim Thema Testen einen Teil der gewonnenen Agilität des Entwicklungsprozesses wieder zunichte. Funktionale Anforderungen werden im jeweiligen Sprint entwickelt und im Sprint Review abgenommen. Das umfangreiche Testen von funktionalen und – insbesondere auch – nichtfunktionalen Anforderungen wird jedoch oft asynchron zum Sprint oder einfach “irgendwann später” gemacht.

Man verschenkt zudem die Möglichkeit, die man durch das häufige Testen kleiner Inkremente hat: Frühzeitiges Erkennen und Beheben von Bugs und Verhinderung von Fehlerkaskaden, also unerkannte Fehler, die Folgefehler mit sich bringen (und deren Analyse meistens aufwendig und zeitraubend ist).
Daher streben agile Teams das “Shift left” Pattern an, also das Heranrücken der Testaktivitäten an den Entwicklungsprozess, der ganz links, also am Anfang einer Iteration steht, daher “Shift left”.

Regressives Testen

Regressives Testen ist ein fester Bestandteil in agilen Projekten. Es bedeutet, dass man bei der Neuimplentierung einer Funktionalität stets überprüft, ob diese Änderung/Erweiterung am Quellcode nicht zu einem anderen Problem führt. Dies gilt auch für Bugfixes, bei denen manchmal ein Fehler behoben wird und gleichzeitig zwei neue Fehler unbeabsichtigt eingebaut werden. 

Die Häufigkeit der Durchführung macht eine Automatisierung dieser Tests zwingend notwendig, um die Schlagzahl der Testdurchläufe realisieren zu können.

Hoher Automatisierungsgrad

Die Anforderungen an eine entwicklungsbegleitende Qualitätssicherung lassen sich am besten mit einem hohen Grad an automatisierten Test- und Deploymentverfahren bedienen. 

Dabei gilt keinesfalls “Viel hilft viel”, man sollte sich stattdessen vorher Gedanken machen, für welche Softwarekomponenten und Akzeptanzkriterien bestimmte Testarten am sinnvollsten sind. Ausserdem sollte die Wiederholbarkeit im Vordergrund stehen, also Tests die voraussichtlich bei jedem neuen Artefakt neu ablaufen werden.

Für die verschiedenen Testarten, z.B.

  • Unit Tests
  • statische und dynamische Codeanalyse
  • Oberflächentests
  • Schnittstellentests
  • Last- & Performancetests
  • Kapazitätstests

gibt es eine Vielzahl von Tools am Markt, sowohl im kommerziellen Bereich, aber auch als Open Source oder Community Projekt. Wir helfen Ihnen gerne bei der herstellerneutralen Auswahl des geeigneten Tools für Ihr Testvorhaben.

Continuous Integration

Meistens werden diese Tools mit Continuous Integration (CI) Werkzeugen wie Jenkins, Octopus oder Bamboo zu sogenannten Pipelines zusammengestöpselt, um automatisiert und regelmässig die Qualität der Software zu überprüfen. In den Pipelines werden der Ablauf der einzelnen Tools und ihre Parametrisierung festgelegt.

Das Starten der Pipeline kann entweder zeitlich gesteuert (z.B. nächtlich) oder ereignisgesteuert (z.B. bei Einchecken von Quellcode im Repository) erfolgen.

In einer erweiterten Variante einer CI-Pipeline kann auch die Auswertung der Testergebnisse anhand von vorher festgelegten Key Performance Indikatoren (KPIs) automatisch erfolgen, sodass ein manueller Eingriff nur bei Abweichung der Ergebnisse von den KPIs erforderlich ist.

Fazit:

Der Vorteil agiler Softwareentwicklung lässt sich nur dann vollständig heben, wenn man auch das Testen der Software agilisiert.

Testautomatisierung ist einer der Schlüssel zum Erfolg, jedoch für sich genommen keine Garantie für eine erfolgreiche agile Qualitätssicherung. Die konzeptionelle Vorarbeit ist nicht zu unterschätzen, zudem muss das Mindset aller am Projekt beteiligten stimmen.

Sollten Sie Rückfragen oder konkrete Anforderungen in den Bereichen “Agiles Testen” oder “Continuous Integration” haben, helfen wir Ihnen gerne mit unserer umfangreichen Projektpraxis in diesem Umfeld. Nehmen Sie gerne einfach Kontakt mit uns auf.