Ein Blick in meine imaginäre Glaskugel verrät mir, dass auch im Jahr 2022 unzählige Softwareentwicklungsprojekte dem Wasserfallmodell oder dem sogenannten Water-Scrum-Fall folgen werden.
All jenen, die noch nicht das meines Erachtens zweifelhafte Vergnügen mit Water-Scrum-Fall hatten, sei gesagt «das wollt ihr nicht erleben». Water-Scrum-Fall ist nach meiner Erfahrung nichts anderes als ein Wasserfall Projekt, das in eine agile Vorgehensweise, meist Scrum, gequetscht wird. Klingt absurd? Ist es auch! Darüber hinaus ist es extrem stressig und frustrierend für die Beteiligten.
Gerne möchte ich an dieser Stelle festhalten, ich spreche nicht von Projekten im regulierten und/oder sicherheitskritischen Umfeld, in welchen ein Vorgehen nach dem V-Modell seine Berechtigung hat. Mein Fokus liegt auf Projekten in Branchen welche ausreichend Handlungsspielraum haben, den Wasserfall hinter sich lassen und die Aussicht auf einen verheissungsvollen Regenbogen geniessen könnten. Die Ausführungen in diesem Artikel beruhen auf meiner persönlichen Erfahrung in verschiedensten Softwareprojekten, unterschiedlichen Branchen sowie Unternehmen.
Ich stieg ins Softwaretesting ein als «Agile» noch am Horizont stand (zumindest in der Schweiz). Zu dieser Zeit war mein Job, mein Einsatz klar. Ich war an der Reihe sobald alle anderen fertig waren. Testing stand am Ende des Prozesses. Good old Waterfall. Wie viele Tester:innen sicherlich bestätigen können, hatte das zur Folge, dass so gut wie nie ausreichend Zeit für vollumfängliches oder zumindest zufriedenstellendes Testing vorhanden war. Das Projekt lief schon beträchtliche Zeit, sämtliche Puffer waren aufgebraucht. Testing musste gemacht werden, aber bitte ohne Abstriche und in der Hälfte der Zeit. Das wiederum resultierte in gestressten, überarbeiteten Tester:innen, einem frustrierten Projektteam quer durch alle Disziplinen und am Ende fehlerhafter Software und unzufriedenen Benutzer:innen.
Ich habe das oft erlebt und mich je länger je mehr gefragt «Werde ich immer der Flaschenhals sein? Wieso lastet die Verantwortung für Qualität auf meinen Schultern, wo doch so viele Menschen an dem Produkt mitgearbeitet haben? Warum werde ich nicht früher einbezogen?». Diese und mehr Fragen haben mich nicht mehr losgelassen. Gute Softwarequalität war und ist mir ein Herzensanliegen. Also habe ich die Ärmel hochgekrempelt und beschlossen neue Wege zu gehen. Ein ganzheitlicher Ansatz musste her, in welchem Qualität als Prinzip verstanden und gelebt wird und nicht als lästiges Übel am Prozessende steht. Qualität kann nicht am Ende hinein getestet werden. Qualität ist die Verantwortung des gesamten Teams, unabhängig von Rolle oder Disziplin. Nur gemeinsam sind wir erfolgreich, effizient und können das richtige Produkt zum richtigen Zeitpunkt ausliefern. Leicht gesagt, aber nicht leicht getan.
Anfang 2019 hatte ich nach einigen Rückschlägen und Umwegen das Glück in einem grossen Projekt zu starten. Endlich bekam ich die Chance ganz nah an der Entwicklung zu sein. Mein konkreter Auftrag war sogar die Qualität und Qualitätssicherung direkt auf Entwicklungsseite zu analysieren und sukzessive zu verbessern. Das war DIE Gelegenheit meine Ideen in die Tat umzusetzen. Ich hatte Unterstützung von oberster Ebene. Was ich jedoch unterschätzt hatte war die Tatsache, dass wir Menschen Gewohnheitstiere sind. Alles was neu oder anders ist, dem stehen wir zunächst skeptisch gegenüber. Es erforderte viel Zeit, Engagement, Diskussionsbereitschaft, Empathie und Verständnis von allen Seiten die folgenden Dinge in Rollen zu bringen, aber es hat sich definitiv gelohnt.
Das Projektteam bestand zu Beginn aus rund 60 Personen aus verschiedenen Disziplinen und wuchs zwischenzeitlich auf mehr als 80 Personen an. Die Mehrheit stellten Entwickler:innen. Die Entwicklung war auf mehrere Scrum Teams aufgeteilt. Die Teams bestanden aus 6-10 Personen. Zudem gab es ein eigenes Testteam. Ein eigenes Testteam? Ja, genau. Das Testteam sass nicht im gleichen Grossraumbüro wie «das Team», sondern in einem abgetrennten Raum über den Flur. Das kam mir komisch vor. Vor allem, weil das Projekt agil organisiert war. Schnell fand ich heraus, dass innerhalb der Scrum Teams agil gearbeitet wurde, das offizielle Testing aber immer noch dem guten alten Wasserfall folgte. Das Feedback zur Qualität der Software floss viel zu spät und äusserst schwerfällig zurück in die Entwicklung. Meine Lösung: Tester:innen in die Scrum Teams, sofort! Das stiess auf wenig Freude, viel Skepsis und teilweise sogar destruktives Verhalten der Betroffenen. Erschwerend hinzu kam, dass in der Vergangenheit bereits versucht worden war Tester:innen in den Teams zu haben, diese sich jedoch als nörgelnde, kritisierende und blockierende Zeitgenoss:innen herausgestellt haben und somit kurzerhand wieder aus den Teams verabschiedet wurden. Davon liess ich mich jedoch nicht beirren. Jeder Mensch ist anders und genau das ist der springende Punkt. Die besten Ansätze, Frameworks, Vorgehensmodelle funktionieren nicht, ohne die passenden Menschen. Alles steht und fällt mit der Haltung, dem vielgerühmten «Mindset», einem Vorhaben gegenüber. Ich beschloss also selbst in ein Scrum Team zu gehen und zu beweisen, dass mein Ansatz funktionieren kann.
Und so fand ich mich als Embedded Testerin in dem einzigen Team ohne GUI (grafical user interface) Komponenten wieder. Das mag für viele keine Erwähnung wert sein. Für mich ist es das, da ich über keine tiefe technische Ausbildung verfüge, meine Programmierkenntnisse sich auf absolutem Basisniveau bewegen und meine gesamte Testingkarriere bis zu diesem Zeitpunkt auf der grafischen Benutzeroberfläche, dem GUI, stattgefunden hatte. Ich hatte grossen Respekt vor der neuen Aufgabe. Rückblickend hätte es jedoch nicht besser kommen können.
Der Umstand, dass ich vor allem in der Anfangsphase nicht selbständig testen konnte, zwang das gesamte Team enger zusammenzuarbeiten und neue Ansätze auszuprobieren. Ich hatte schon immer eine schnelle Auffassungsgabe und ein gutes technisches Verständnis. Diese Eigenschaften ermöglichten es mir schnell in die Themen und Verantwortlichkeiten meines Teams einzutauchen. Rasch verstand ich, dass ich mein Team weniger mit der Ausführung von Tests, sondern vielmehr mit meiner Expertise in smartem Testdesign, Reviews und mit kritischen Fragen unterstützen könnte. Und auf einmal war er da, der Regenbogen jenseits des Wasserfalls.
Wir analysierten gemeinsam unsere Testabdeckung beginnend bei der untersten Ebene, den Unittests. Wir waren stets offen für Ideen und wagten uns an Behaviour Driven Development (BDD a.k.a. Specification by example). BDD brachte uns eine gemeinsame Sprache, unabhängig von unseren Disziplinen. Das gesamte Team verstand die Anforderungen so klar und eindeutig wie nie. Zusätzlich hatten wir im selben Arbeitsschritt konkrete Testszenarien definiert, bevor auch nur eine Zeile Code geschrieben war. Das brachte uns eine immense Zeitersparnis. Die Testszenarien konnten zudem auf jeder Teststufe verwendet werden. Die enge und unmittelbare Zusammenarbeit im Team und das Wissen über die konkrete Testabdeckung auf allen Teststufen ermöglichten es mir manuelle Testfälle auf ein Minimum zu reduzieren. Endlich konnte ich meine Fähigkeiten von Beginn an einbringen, Built-in Quality vorantreiben und mich mit spannenden, explorativen Tests beschäftigen. Die hohe Eigendisziplin jedes einzelnen Teammitglieds sowie die konsequente Nutzung automatischer CI/CD (continuous integration/continuous deployment) Pipelines und entsprechender Quality Gates machten uns erfolgreich. Ausserdem reflektierten wir uns laufend selbst, passten Dinge an, verbesserten sie oder warfen sie über den Haufen.
Schon nach wenigen Monaten war mein Team ein Vorbild für rollenübergreifende Zusammenarbeit und Qualitätssicherung innerhalb des Projekts. Es dauerte nicht lange und wir waren das Vorzeigebeispiel über die Projektgrenzen hinaus. Viele fragten nach unserem Geheimnis.
Es klingt so einfach und ist doch schwer umsetzbar: es braucht den richtigen Mix an Menschen, mit den passenden Fähigkeiten, die Bereitschaft aller gemeinsam an einem Strang zu ziehen, vor allem dann, wenn es mal nicht so gut läuft.
Wer das beherzigt und mit ein bisschen Glück zum richtigen Zeitpunkt am richtigen Ort ist, die/der hat gute Aussichten das Glitzern des Goldes im Topf am Ende des Regenbogens zu sehen.
Ich wünsche uns allen für die Zukunft mehr Miteinander, Offenheit, Akzeptanz, spannende Projekte und ganz viele Regenbögen, denn so macht Qualitätssicherung und Testing viel mehr Spass.