Agile / Software-Test

Todgesagte leben länger – Testen nach (mit) dem Agilen Manifest

Agile Prinzipien und Methoden haben in der Diskussion im deutschsprachigen Raum Hochkonjunktur. Ein Aspekt daraus ist das Verhältnis von agilen Prinzipien und Test. Wie passen sie zusammen? Sind Tester im agilen Setting eine aussterbende Spezies? Lassen Sie uns gemeinsam einen Blick auf die Argumentationskette werfen und erklären, weshalb die agilen Prinzipien von Grund auf den Test fördern und fordern.

freestocks-org-540554_blog

Als 2001 das agile Manifest unterzeichnet wurde und vor allem Scrum in den darauffolgenden Jahren von sich reden machte, dachten viele bereits, dass der Test überflüssig würde. Auf den ersten Blick schien das so. Dennoch gilt wieder einmal das alte Sprichwort: Totgesagte leben länger.

Bis die Agile Bewegung in Deutschland und Österreich flächendeckend Einzug hielt, vergingen noch einige Jahre. Eine Schonfrist, wie von manchem strikten Agilisten und SCRUMRitter gescherzt wurde. Die Tester-Szene im deutschsprachigen Raum war beunruhigt und um ihre Zukunft besorgt: Auflösung der Rollen, jeder kann und macht alles – „Braucht es da noch einen Tester?“ lautete die bange Frage. Während die einen damals vorhersagten, dass es bald kein Rollenbild Tester mehr geben würde, zeigt sich heute ein gänzlich anderes Bild in den Projekten.

 

Der Software-Tester als Bestandteil eines interdisziplinären Teams

Im agilen Entwicklungsprozess sind Tester Teil des interdisziplinären Teams und gemeinsam mit Entwicklern, Analytikern, Architekten und Kundenvertretern von Beginn an im Projekt involviert. Jeder ist verantwortlich für das Ergebnis und damit für die Qualität. Aus diesem interdisziplinären Denken heraus übernehmen alle Personen im Team verstärkt Arbeiten abseits ihrer zentralen Aufgabenstellung.

Dieser Wandel im Denken ist auch für den Tester eine Herausforderung. In agilen Teams kann der Entwickler Testaufgaben übernehmen und der Tester Entwicklungsaufgaben – je nach Maßgabe und Skill-Entwicklung. Anzunehmen, dass dies so einfach möglich ist, wäre jedoch ein Fehler. Weder ist ein gelernter Entwickler auf Knopfdruck ein guter Tester noch sind Tester automatisch mit entsprechender Programmiererfahrung ausgestattet. Gleichzeitig ist die Entscheidung, nicht alle Software Engineering Disziplinen auf hohem Niveau im Team vertreten zu haben, fatal. Gerade agile Methoden verlangen höchste Expertise und Erfahrung.

 

Die Praxis lebt Hybrid

In unserer Funktion als Berater, begleiten meine Kollegen und ich viele unterschiedliche Unternehmen. Was sie (fast) alle eint, ist eine Hybridform aus Agil und Klassik. Warum die „reinen“ agilen Projekte nach wie vor in der Minderzahl sind, hat mehrere Gründe:

  • Die Größe des Unternehmens: In Großunternehmen und ihrer traditionellen Aufbauorganisation, die sich meist an klassischem Projektmanagement orientiert, entwickelten sich vermehrt Mischformen aus agilem und klassischen Vorgehen. Hingegen kleine Unternehmen oder Start-Ups setzen als „Agile Natives“ bereits mit der Firmengründung auf rein agile Methoden.
  • Gesetzliche Vorgaben: In manchen Branchen zwingt der Gesetzgeber aus Sicherheitsgründen durch Nachweispflichten und Bestimmungen geradezu ein klassisches Projektmanagement auf.
  • Das Mindset des Einzelnen und die Unternehmenskultur: Der Einsatz agiler Praktiken bedeutet noch lange nicht, wirklich agil zu sein. Denn dazu gehört neben der entsprechenden Einstellung, dem Mindset, der agierenden Personen vor allem eine Unternehmenskultur, die agile Entwicklung zulässt, ohne sie einzuengen. Gewohnte Routinen und festgefahrene Prozesse führen dazu, dass agile Vorgehen zwar am Papier angewandt, sie aber sozusagen von innen heraus wieder zum klassischen Vorgehen hinauf skaliert werden – ohne die Best Practices zu beachten, die im Rahmen der bimodalen IT bereits gesammelt wurden.

 

Agilen Prinzipien als Manifest für den Test

Fakt ist, selbst die strengsten Agilisten und SCRUMRitter haben bereits erkannt, dass auf Test und Qualitätssicherung nicht verzichtet werden darf und kann. Die Existenz einer eierlegenden Wollmilchsau ist und bleibt eine Mär. Gleichzeitig ist unumstritten, dass sich der Test an sich verändert und weiterentwickelt. Wir greifen acht Prinzipien des Agilen Manifests auf und erläutern die Veränderungen, die Chancen und die Unterstützung, die der Test durch sie erfährt:

 

„Unsere höchste Priorität ist es, den Kunden durch
frühe und kontinuierliche Auslieferung wertvoller Software,
zufrieden zu stellen“

 

Damit dieses oberste agile Prinzip gewährleistet wird, sprich dem Kunden wirklich wertvolle Software geliefert wird, ist eine frühe und kontinuierliche Qualitätssicherung der gelieferten Produkte notwendig. Dies erfordert den Einsatz entspre­chender Testmethoden und Werkzeuge sowie das Mitwirken von Teammitgliedern mit hoher Expertise im professionellen Software-Test. Genau betrachtet bewegt sich hier der Unterschied zwischen traditionellem und agilem Vorgehen gegen Null.

 

„Heiße Anforderungsänderungen selbst spät in der Entwicklung
willkommen. Agile Prozesse nutzen Veränderungen
zum Wettbewerbsvorteil des Kunden.“

 

Eigentlich der Alptraum jedes Testers. Gerade Änderungen in letzter Minute bergen das hohe Risiko, dass mögliche Auswirkungen nicht berücksichtigt werden. Jede fachliche oder technische Modifikation bedarf neben deren Tests ebenso eines Regressionstests von bereits durchgeführten Prüfungen, inklusive der Anpassung entsprechender Testfallpakete.

Agile Methoden sehen dafür kaum Zeit vor. Daher scheint die Automatisierung des funktionalen Regressionstests einerseits ein Muss für agile Projekte, andererseits ist diese eben durch die ständigen, potentiellen Änderungen und Erweiterungen schwer und nur mit entsprechendem Aufwand zu gewährleisten. Hier gilt es abzuwägen, ob und was automatisiert wird. Was in diesen Situationen zählt sind die Erfahrungswerte der Tester.

 

„Liefere funktionierende Software regelmäßig innerhalb
weniger Wochen oder Monate und bevorzuge dabei
die kürzere Zeitspanne.“

 

Dieses Prinzip steht in engem Zusammenhang mit den zuvor genannten. Die Lieferung von funktionierender Software in kurzen und regelmäßigen Abständen setzt einen professionell aufgesetzten Test geradezu als Selbstverständlichkeit voraus.

Der Vorteil kurzer und regelmäßiger Feedbackschleifen ist, rasch auf Änderungswünsche reagieren zu können. Nach ihrer Implementierung sind die Änderungen im gleichen Rhythmus laufend zu testen.

 

„Die effizienteste und effektivste Methode, Informationen
an und innerhalb eines Entwicklungsteams zu übermitteln,
ist im Gespräch von Angesicht zu Angesicht.“

 

Dieses Prinzip bietet Chance und Risiko in einem.  Selbst wenn es stimmt, so setzt es voraus, dass ALLE Betroffenen anwesend sind und das gleiche verstehen. Wer kennt nicht das Kinderspiel „Stille Post“ und weiß um die Risiken, die durch die informelle Weitergabe von Anforderungen entstehen. Mit seinem naturgegebenen kritischen Blick und dem konsequenten Hinterfragen vermeintlicher Tatsachen übernimmt der Tester die Schärfung der Anforderungen und bringt neue Sichtweisen ein. In jedem Projekt kommt früher oder später der Zeitpunkt, wo Unklarheiten bzw Uneinigkeiten aufgedeckt werden – oft auch von außerhalb des Projekts, wie etwa dem Betrieb. Nicht selten sind die Testfälle dann die einzige Dokumentation der Funktionalität.

 

„Funktionierende Software ist das wichtigste Fortschrittsmaß.“

 

Die Betonung des Adjektivs „funktionierend“ ist seit jeher eine Herzensangelegen jeden Testes und eine Forderung, die er mit aller Kraft unterstützt. Was dabei unabhängig von Kennzahlen, wie etwa verbrauchtem Budget, zählt ist, dass die Software funktioniert und den Kundenwünschen entspricht. Als Tester liefern wir mit unserer Expertise einen entscheidenden Beitrag dazu.

 

„Einfachheit — die Kunst, die Menge nicht getaner
Arbeit zu maximieren — ist essenziell“

 

Vorauseilender Gehorsam und Selbstverwirklichung der Entwicklung sowie gut gemeinte Features, die eingebaut wurden, haben den Test immer schon vor eine besondere Herausforderung gestellt. Auch dieses Prinzip unterstützt Forderungen seitens des Tests – auch ganz nach dem Prinzip „KISS – Keep it Short and Simple“. Wird zu viel vereinfacht, kommt der Test wieder ins Spiel, der die Kundenbedürfnisse als primäres Ziel im Auge hat.

 

„Die besten Architekturen, Anforderungen und
Entwürfe entstehen durch selbstorganisierte Teams“

 

Das Vertrauen des Managements in seine Teams ist Grundvoraussetzung für die langfristige erfolgreiche Zusammenarbeit selbstorganisierter Teams. Es bedarf einer ‚gesunden‘ Fehlerkultur, sprich dem Zulassen von Fehlern. Oftmals übernimmt der Tester die Aufgabe, Architekturen, Anforderungen und Entwürfe kritisch zu hinterfragen und trägt so wesentlich zur Vertrauensbildung den Stakeholdern gegenüber dem Team bei. Schlussendlich ist es aber DAS TEAM, das sich weiterentwickelt, verbessert und erfolgreich ist.

 

„In regelmäßigen Abständen reflektiert das Team,
wie es effektiver werden kann und passt sein
Verhalten entsprechend an“

 

Überspielte Schwächen und unbemerkte Lücken entdecken ist des Testers Spezialität. Diese Phase der kritischen Selbstreflektion ist Voraussetzung für eine tatsächliche Verbesserung. Andernfalls besteht die Gefahr, dass es dem Team wie den Affen aus dem Dschungelbuch, den Bandar-Logs, ergeht: „We are wonderful. We are the most wonderful people in all the jungle! We all say so, so it must be true!“

 

Lessons learned

Was haben wir daher aus mehr als 15 Jahre Agiles Manifest gelernt? Die Anforderungen an den Tester haben sich geändert, die Verantwortung für erstklassige Qualität von Software allerdings ist unverändert hoch.

Weiterhin ist der Test essentiell! Und das professionell. Charakteristisch für agile Projekte sind der flexible Testprozess und die Kombination mehrerer Testmethoden, etwa explorative Tests, Story Tests, automatisierte Tests. Je nach Voraussetzungen und Rahmenbedingungen gibt es unterschiedliche Ausprägungen hinsichtlich Organisation und Optimierung von Testaktivitäten.

Wie bereits Martin Fowler ausführte, ist der „Self-Adaptive Process“ ein wichtiger Wesenszug agiler Ansätze. Leicht gesagt, denn gerade das Mittragen und Lebendig halten des permanenten systemimmanenten Wandels ist die eigentliche Herausforderung für Mitarbeiter.  Ein „Nebenbei-Testen“ durch Entwicklung oder Product Owner ist zu wenig.

Das Berufsbild des Testers mag sich gewandelt haben, auf ihn verzichtet werden kann definitiv nicht.  Wie gesagt: Totgesagte leben länger!

Passende Artikel

Antwort schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*