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 klassischem Vorgehen. Hingegen setzen kleine Unternehmen oder Start-ups 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.
Agile 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 zufriedenzustellen“
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 entsprechender 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 Albtraum 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, potenziellen Ä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.
Als Best Practice aus einer Vielzahl agiler Projekte hat sich gezeigt, dass pro User-Story mindestens zwei Testfälle zu automatisieren sind – ein positiver und ein negativer Testfall. Zusätzlich gibt ein risikobasierter Testansatz einen wichtigen Richtwert für die Testabdeckung durch die Testautomatisierung vor.
„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. Als international aufgestelltes Unternehmen ist es Nagarro gewohnt, in verteilten Teams zu arbeiten. Dank der neuen Technologien ist es für eine gute Zusammenarbeit zweitrangig, wo der tatsächliche Arbeitsplatz ist. Hingegen wird die kulturelle Komponente oft unterschätzt. Denn „verstehen“ und „gleich interpretieren beziehungsweise bewerten“ können zwei unterschiedliche Dinge sein. Tester fordern durch mehrmaliges Nachfragen Klarheit ein und helfen dadurch, Interpretationsspielräume zu minimieren.
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 beziehungsweise 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 jedes Testers 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 nicht nur funktioniert, sondern auch den Kundenwünschen entspricht. Ein Erfolgsfaktor in vielen Projekten ist daher eine enge und gute Zusammenarbeit der Tester mit dem Product Owner.
Als Tester liefern wir mit unserer Expertise einen entscheidenden Beitrag im frühen Verstehen und Schärfen der Storys, im gemeinsamen Ableiten der Akzeptanzkriterien oder schlussendlich auch im Vorbereiten und Begleiten der Reviews.
Es bewährt sich auch, wenn Tester einen aktiven Part bei den Anwenderschulungen einnehmen. Oft kommen aus den Schulungen die Anforderungen für die nächsten Storys.
„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 der Stakeholder 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 zu 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 Jahren 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 essenziell! 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!
