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

06.09.2017
Renate Weichselbraun und Clemens Mucker

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 passt diese zusammen? Sind Tester im agilen Setting eine aussterbende Spezies?
Wir heizen die kontroverse Diskussion mit einer These an: Das agile Manifest, ein Manifest für den Test! Provokant? Ja! 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.
 
Als 2001 das agile Manifest unterzeichnet wurde und vor allem SCRUM in den darauffolgenden Jahren von sich reden machte, dachten viele bereits, dass der Tests ü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 SCRUM-Ritter 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 wir sehr 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:

  1. Die Größe des Unternehmens:
    Oft werden einzelne IT-Projekte zwar agil abgewickelt. Da das Gesamtunternehmen auf klassisches Projektmanagement hin orientiert ist, ergibt sich durch die internen Strukturen eine Mischform aus agilem und klassischem Vorgehen. Nur wenige „Agile Natives“ setzen seit der Firmengründung rein agile Methoden ein.

    In Großunternehmen und ihrer traditionellen Aufbauorganisation, die sich meist an klassischem Projektmanagement orientiert, entwickelten sich vermehrt Mischformen aus agilem und klassischem Vorgehen. Kleine Unternehmen oder Start-Ups setzen hingegen als „Agile Natives“ bereits mit der Firmengründung auf rein agile Methoden.
  2. Gesetzliche Vorgaben:
    In manchen Branchen zwingt der Gesetzgeber aus Sicherheitsgründen durch Nachweispflichten und Bestimmungen geradezu ein klassisches Projektmanagement auf.
  3. 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 SCRUM-Ritter 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. 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 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 Test 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 das Risiko, das durch die informelle Weitergabe von Anforderungen entsteht. 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 Herzensangelegenheit 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. Wir Tester liefern 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 mit diesem Prinzip ist der Test nicht überflüssig geworden. Vielmehr unterstützt es nur 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 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!“ (deutsche Übersetzung: »Wir sind mächtig. Wir sind frei. Wir sind schlechthin großartig. Wir sind das herrlichste Volk in der ganzen Dschungel. Wir alle sagen es, und deshalb muss es wahr sein!“ – so steht es wirklich in der deutschen Ausgabe)
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 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 Lebendighalten des permanenten systemimmanenten Wandels 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!
[toggle type=”” title=”Autoren Renate Weichselbraun und Clemens Mucker”]Renate Weichselbraun

Leitung Testing Services
 
3 Worte über mich
neugierig, sozial, strukturiert
 
ANECON steht für
Mitarbeiterinnen und Mitarbeiter mit hohem fachlichen Know-how und hoher sozialer Kompetenz.
 
Mein Lebensmotto ist
Lieber ein Optimist, der sich ab und zu irrt, als ein Pessimist, der immer Recht hat.
 
Zertifizierungen
ISTQB® Certified Tester Advanced Level Test Manager und Test Analyst, IREB® Certified Professional for Requirements Engineering, QAMP®, iSQI® – Certified Agile Tester, iSQI® CMAP©Certified Mobile App Professional, IPMA Level C®
 
Seit 2008 ist Renate Weichselbraun als Software-Test Beraterin bei ANECON tätig und ihre Schwerpunkte liegen im Testmanagement, Software-Qualitätsmanagement, Testprozessberatung und -optimierung sowie dem Abhalten von Trainings und Workshops. Schon während des Kurzstudiums der Datentechnik an der TU Wien arbeitete Renate Weichselbraun bei Coca-Cola Computer Services im Bereich Software-Test und Quality Control. Hier sammelte sie mehr als 10 Jahre umfangreiche Erfahrungen als Testspezialistin und Testkoordinatorin von Integrations-, System- und Abnahmetests in einem internationalen Unternehmen.

 
Clemens Mucker

Berater Software-Test
 
Zertifizierungen
ISTQB® Certified Tester Full Advanced Level, IREB® Certified Professional for Requirements Engineering, QAMP®, IPMA®, Certified ScrumMaster®
 
Clemens Mucker kam im Jahr 2000 über Umwege zum Software-Test, seit 2003 engagiert er sich nebenberuflich im Austrian Testing Board. Nach Testprojekten in Deutschland und der Schweiz ist er seit 2009 für ANECON als Senior Test Consultant tätig. Zu seinen Hauptaufgaben zählen – neben der Projektleitung – Testkoordination und Testmanagement. Die Schwerpunkte liegen dabei auf System- und Abnahmetests, der Einführung von Software-Test in Unternehmen und dem Aufbau von Testteams. Seine Erfahrung als Requirements Engineer bringt er auch im Coaching von Testteams und Testmanagern ein.

[/toggle]

3 Kommentare

  1. Timea

    Hallo Renate
    ich bin auf deinen interessanten Artikel gestoßen. Finde ihn sehr hilfreich. Vor allem aber deine Erläuterungen zum agilen Entwicklungsprozess, finde ich mehr als gelungen und sehr empfehlenswert. Danke dafür. Hat mich echt inspiriert.
    Liebe Grüße
    Timea

    Antworten
  2. Marco

    Hallo Renate,
    mit großem Interesse habe ich Deinen Artikel gelesen. Du hast die Situation in vielen Firmen auf den Punkt gebracht. Allerdings fehlt mir komplett, wie sich die Arbeit eines klassischen Testmanagers konkret in Zukunft ändern wird. Vielleicht kannst Du Deine Gedanken dazu noch kommentieren.
    VG Marco

    Antworten
  3. Richard

    Hallo Renate,
    halle Clemens,
    hätte ich nicht besser beschreiben können. Spiegelt meine Erfahrungen in einem hybriden Projekt als Testkoordinator/Tester wieder. Schade das das Thema “Test” häufig noch als lästiges übel am Ende eines Projektes angesehen wird, quasi so als Nebenaufgabe die schnell erledigt sein muss.
    Hier muss sich Vor allem das Mindset der Mitarbeiter aber Vor allem der PL deutlich ändern. Viele PL leben nach dem Prinzip “Nach mir die Sinn Flut”.
    VG
    Richard

    Antworten

Einen Kommentar abschicken

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.