Glaubt man Marktforschungsunternehmen wie Gartner, wird die Zukunft des Testens anders aussehen. „Qualitätssicherung, wie wir sie kennen,” sei ein Auslaufmodell postuliert Gartner [Gar18]. Gräbt man tiefer und sucht nach den Gründen für diese Einschätzung, tauchen schnell Begriffe wie agile Softwareentwicklung und der Umbau von Unternehmen in Richtung auf DevOps-Strukturen und Business-Agilität auf. Für Menschen, die sich in solchen Umbauphasen befinden und die den Schwerpunkt auf Test, Qualitäts- und Führungsverantwortung haben, finden sich nicht immer leicht Hilfestellung und Anleitung.
ATLaS will Abhilfe schaffen und Theorie mit Praxisbeispielen verknüpfen. Der Grund für den ATLaS-Lehrplan des ISTQB ist die feste Überzeugung, dass auch und gerade in agilen Entwicklungsprojekten zielführendes Testmanagement notwendiges Beiwerk zum Erfolg ist. Natürlich stellt sich die Frage, was man testaffinen Menschen mit auf den Weg gibt, um Unternehmen zu helfen, die sich das Ziel gesetzt haben, Business-Agilität zu erreichen. Wo hört man mit allgemeiner Agilität @ Scale auf, die ja auch in verschiedenen Skalierungs-Frameworks wie LeSS, SAFe oder Nexus beschrieben ist? Wo fängt das Testen an, ein Thema für Skalierung zu sein? @ Scale geht über die Teamgrenzen hinaus. ATLaS [ATLaS] will sich nicht auf ein Skalierungs-Framework festlegen, aber Kernaussagen aus jedem der Frameworks können nützliche Kenntnisse für Tester sein.
Total Quality Management
Den Ton in ATLaS gibt das erste Kapitel vor, das mit dem Titel „Quality Assistance” überschrieben ist. Viele agile Skalierungsframeworks berufen sich auf Lean Agile. Aus dem Lean Management stammt ein bekannter Ansatz für Qualitätsmanagement, der sich TQM, Total Quality Management, nennt und eng mit dem Namen W. Edwards Deming verknüpft ist. Jetzt könnte man bei dem Begriff total vermuten, dass TQM völlig unagil sei. Total im Sinne von totaler Macht für Manager? Tatsächlich ist das Gegenteil der Fall. Total sollte in diesem Fall eher im Sinne eines alles umfassenden Blicks verstanden werden. Im Lean Lexicon [LEI] wird TQM als Ansatz beschrieben, in dem alle Abteilungen, Mitarbeiter und Manager verantwortlich sind für eine kontinuierliche Qualitätsverbesserung. Das ist es, wonach Qualitäts- und Testmanagement über Teamgrenzen hinaus streben sollte, um Business-Agilität voranzutreiben (siehe Abbildung 1).
Hauptsächlich der Kontrolleur niedergeschriebener Anforderungsabdeckung zu sein, ist ein Auslaufmodell. Agiles Testmanagement bewegt sich, wie alle agilen Management-Rollen, stark in die Verantwortung, Strukturen und Möglichkeiten zu fördern, damit Test- und Qualitätspraktiken auf breiter Front erprobt werden und sich über Teamgrenzen hinaus etablieren. Anders gesagt: Qualitätsmanagement funktioniert über einen „Quality Assistance”-Ansatz. Wenn Edwards Deming sagt: „Quality is a management responsibility that cannot be delegated”, meint er genau das. Die Management-Aussage „agile Teams oder die agilen Scrum Master müssen sich von selbst um Qualität kümmern” ist keine akzeptable Übertragung von Verantwortung. Denn Qualität kann nur in den Rahmenbedingungen gedeihen, die ein Unternehmen steckt. Die Frage, wenn es schief geht mit der Qualität, ist immer: Was hätte man für Rahmenbedingungen erproben und festigen müssen, damit „Built-in Quality” auch an den Stellen klappt, wo es bisher nicht oder nicht mehr funktioniert. Change Leadership, Qualitätscoaching, Moderation und Training gehören in den Werkzeugkoffer für Test Leadership @ Scale.
Abb. 1: Quality Assistance-Ansatz im Qualitätsmanagement
Hauptsächlich der Kontrolleur niedergeschriebener Anforderungsabdeckung zu sein, ist ein Auslaufmodell. Agiles Testmanagement bewegt sich, wie alle agilen Management-Rollen, stark in die Verantwortung, Strukturen und Möglichkeiten zu fördern, damit Test- und Qualitätspraktiken auf breiter Front erprobt werden und sich über Teamgrenzen hinaus etablieren. Anders gesagt: Qualitätsmanagement funktioniert über einen „Quality Assistance”-Ansatz. Wenn Edwards Deming sagt: „Quality is a management responsibility that cannot be delegated”, meint er genau das. Die Management-Aussage „agile Teams oder die agilen Scrum Master müssen sich von selbst um Qualität kümmern” ist keine akzeptable Übertragung von Verantwortung. Denn Qualität kann nur in den Rahmenbedingungen gedeihen, die ein Unternehmen steckt.
Die Frage, wenn es schief geht mit der Qualität, ist immer: Was hätte man für Rahmenbedingungen erproben und festigen müssen, damit „Built-in Quality” auch an den Stellen klappt, wo es bisher nicht oder nicht mehr funktioniert. Change Leadership, Qualitätscoaching, Moderation und Training gehören in den Werkzeugkoffer für Test Leadership @ Scale.
Value Stream Mapping
Ein weiteres Instrument aus dem Lean-Werkzeugkoffer ist die Fähigkeit, Einzelabteilungen in einer Wertschöpfungskette zu sehen und zu analysieren. Das nennt sich Value Stream Mapping. Zum Analysieren eines Value Streams aus der Qualitäts- und Testperspektive gehören Elemente, die Testmanagern schon immer wichtig waren. Zum Beispiel die Frage, wie häufig Fehler oder unvollständige Lösungen über die Stationen einer Wertschöpfungskette entlang weitergereicht werden. „Percent complete and accurate (%C&A)” ist der Prozentsatz der Fälle, in denen ein Bearbeitungsschritt vollständig und genau (Done) abgearbeitet wird, sodass die Mitarbeiter des nächsten Arbeitsgangs ihre Tätigkeit auch wieder abschließen können, ohne dass sie Teile nacharbeiten oder Informationen finden müssen, die hätten bereitgestellt werden sollen. Solche Qualitätskennzahlen, insbesondere auch Verweildauern von Arbeitspaketen in einzelnen Arbeitsschritten (Lead Time), werden typischerweise in Value Stream Maps analysiert (siehe Abbildung 2).
Abb. 2: Beispiel einer DevOps Value Stream Map
Der Blickwinkel darauf, was genau in einer Wertschöpfungskette effizient und was Verschwendung (Waste) ist, ändert sich unter agilen Vorzeichen. Wie entwickelt ein Leader @ Scale eine zu Business-Agilität passende Vision für die Zukunft? Für Tester ist das wichtig, weil ausgedehnte Systemteststufen einen der häufigeren Fälle von „Lean Waste” innerhalb von Value Streams darstellen. Systemteststufen können zu Warten, Überproduktion und (späten) Korrekturen beitragen. Das wären dann schon mal drei der acht Arten von Verschwendung, die das Lean Management kennt. Anderseits bildet der Systemtest vielleicht einfach das zum gegebenen Zeitpunkt unverzichtbare Qualitätsfangnetz, ohne das Lieferqualität existenzbedrohend leidet.
Die Analyse ist selten einfach, und agile Testleadership @ Scale sollte sie mit vorantreiben. Eine Ursachenanalyse von Fehlern als Teil des „Shift left” schafft die Möglichkeit, die Art und Weise zu ändern, wie Mitarbeiter entwickeln und testen. Testmanagement ist in diesem Kontext zielführend in der Herangehensweise eines fördernden „Quality Assistance”-Ansatzes aufgehoben. Systemtestabteilungen sind nicht automatisch überflüssig, weil Qualitätssicherung die agilen Teams machen. Aber Systemtest sollte selbst Treiber dafür sein, Situationen zu erkennen und schrittweise aufzulösen, in denen das Testen zum wichtigsten Flaschenhals und damit Quelle von Verschwendung (Waste) geworden ist.
Eine Weisheit des Lean Management ist es, dass die Optimierung auf Vollauslastung von Einzelarbeitsstationen (das sind im Fall agiler Softwareentwicklung meistens Menschen) zu erheblicher Verschwendung im Gesamtsystem führt. Es kann also durchaus effizienter sein, eine Systemtesttätigkeit mehrfach frühzeitig zu wiederholen und den Aufwand zu treiben, Wissen breit zu streuen, als scheinbar effizient den spezialisierten Systemtest voll auszulasten. Dazu gehört, dass die Mitarbeiter aller Abteilungen und Rollen in ihrer Arbeit wachsen und verstehen, wie sich Qualität und Tests auf die Leistung eines Value Streams auswirken. Das bietet ein weites Betätigungsfeld für Agile Test Leadership @ Scale.
Rollenmodell
Apropos Agile Test Leadership @ Scale im Kontext von wirklich lebendigen Zeitgenossen:
- Wir wissen alle aus dem Scrum Guide, dass es eine gute Idee ist, rollenübergreifend zu agieren und Rollenmodelle aufzulösen.
- Change Leadership, Qualitätscoaching, Moderation und Training sind alles Verhaltensweisen die auch Scrum Master vorleben und fördern können und sollen.
Inhaltlich soll das Gesagte für einen Einblick in Lehrplaninhalte genügen. Zusammengefasst geht es um Skalierung von Test- und Qualitätssicherungsmaßnahmen durch die Förderung eines Qualitätsdenkens und einer Qualitätskultur im gesamten Unternehmen. Dazu gehört die Umstellung von einem traditionellen Testmanagement-Ansatz, der typischerweise in sequenziellen Entwicklungsmodellen verwendet wird, auf einen qualitätsunterstützenden Ansatz, der auf den Prinzipien und Werten von Lean und Agile aufbaut. Dazu gehört auch die Übernahme gängiger Lean- und Agile-Techniken und -Prozesse zur Analyse und Lösung von Problemen und deren Einsatz zur Verbesserung von Tests und Qualität im Unternehmen.
Zielgruppe und Status
Für wen könnte ATLaS interessant sein? Die Zertifizierung selbst benennt als Zielgruppe Personen, die in einer Organisation arbeiten, die Agilität im großen Maßstab oder Business-Agilität anstrebt, und die sich bereits mit Agilem und agilem Testen auskennen. Diese Zertifizierung sei von großem Nutzen für Rollen wie: Testmanager, Testleiter, Testanalytiker, Qualitätsingenieur, Qualitätssicherer, Qualitätscoach, Mitglied eines agilen Teams, Mitglied der Führungsgruppe mehrerer agiler Teams, Projektmanager, Release Train Engineer oder Scrum Master.
Ein wenig klingt das nach Gemischtwarenladen. Andererseits ist es auch wieder nicht so erstaunlich, denn wenn Qualitätsverantwortung weiter gestreut werden soll, ist natürlich die Bandbreite an Personen, die sich damit beschäftigen sollte, wie Qualität in großem Umfeld funktioniert, auch entsprechend groß. Ein Projektmanager oder Scrum Master würde vielleicht mehr auf die Möglichkeit, eigene Ideen in einer geschützten Trainingsumgebung mit dem von ATLaS gesagten zu vergleichen und zu diskutieren, Wert legen und auf eine formale Prüfung nach dem Training verzichten. Für Tester im agilen Team, die schon praktische Erfahrung mit Testautomatisierung und DevOps-Toolketten haben, und ISTQB Zertifizierungen wie Agile Tester und Agile Technical Tester vorweisen können, geht es vielleicht mehr um den Management-Überbau und auch um den Nachweis per Zertifikat, für Aufgabenstellungen über die Grenzen des eigenen Teams hinaus befähigt zu sein.
Aktuell sind die ersten drei Kapitel von AT-LaS freigegeben und auf der ISTQB-Webseite [ATLaS] veröffentlicht. An weiteren Themen zu ATLaS wird gearbeitet. Zum Beispiel fehlen noch Vertiefungen zu organisatorischer Teststrategie in einem Business agilen Unternehmen. Ein Zeitpunkt, zu dem ATLaS im deutschsprachigen Raum als formales ISTQB-Zertifizierungsprodukt freigegeben wird, steht noch nicht fest. Mit den Inhalten kann man sich trotzdem auch heute schon beschäftigen.
Um zuletzt auf den Anfang zurückzukommen: Dem Lernen im Team muss @Scale das Lernen der Organisation als Ganzes anbei gestellt werden (lernende Organisation) [Sen90]. Aber gleichzeitig kann der Blick über den Tellerrand den Köcher für interessante Verbesserungsexperimente auch für Qualitätssicherer füllen. Sei es durch Studium der Ideen in agilen Skalierungsframeworks, oder eben auch durch einen Blick auf Agile Testleadership @ Scale mit ISTQB ATLaS.
Referenzen
[ATLaS]
ISTQB®, Agile Test Leadership at Scale, International Software Testing Qualifications Board, 2021, siehe:
https://www.istqb.org/certification-path-root/agile-test-leadership-at-scale.html
[Gar18]
Gartner, DevOps and cloud speed are driving the end of QA as we know it, Stamford, 13.8.2018
[LEI]
Lean Enterprise Institute, Lean Lexicon: A Graphical Glossary for Lean Thinkers, 5th Edition, Cambridge: Lean Enterprise Institute, Inc., 2014
[Sen90]
P. M. Senge, The Fifth Discipline: The Art and Practice of The Learning Organization, New York: Doubleday Dell, 1990
