Der Platz von Testern in SAFe
Wo ist der Platz von professionellen Testern oder ausgesprochenen Testspezialisten in agilen Teams? Diese Frage ist schon oft beleuchtet worden. Inzwischen gesteht man Scrum-Teams zu, so etwas wie den Tester in ihrem Team zu haben, auch wenn Testen eine Aufgabe aller im Team ist und bleiben soll. In großen agilen Projektumfeldern mit vielen Teams (die zum Teil unterschiedliche agile Praktiken verwenden) ist diese Frage nicht so einfach zu beantworten. Das Bedürfnis nach Spezialisierung auch im Test ist groß und da braucht es sinnvolle Lösungen auch für Qualitätssicherung.
Ein Kollege berichtete mir kürzlich aus einem Agilen Change-Projekt. Dort wusste man beim Umstellen auf eine nach SAFe [1] orientierte Organisation nicht so recht, was man mit den Testern und Testmanagern aus der bisherigen Organisation machen sollte? Nach langem hin und her – für die Tester durchaus auch örtlich zu verstehen – entschied man sich für das in SAFe definierte Systemteam. Aber ist das der Weg?
Warum der Platz von Testspezialisten wichtig ist?
Grundsätzlich ist die Qualitätssicherung im Agilen eine Teamaufgabe und Testen – wie bereits erwähnt – geht alle an. In einzelnen Teams machen sich Universalisten sehr gut, die neben reinem Test auch programmieren, automatisieren und analysieren können. Je nach Neigungen und Bedarf im Team spezialisert man sich dann ein wenig oder bildet sich nach.
Derzeit erleben wir aber, dass die großen Herausforderungen in der IT (z. B. Industrie 4.0, IoT, Big Data) die Arbeit in den Teams immer komplexer werden lassen. Große Programmteams, ausgesprochene Technologie-Experten, Task-Forces für Sicherheit, etc. sind unerlässlich. Es gibt daher auch nicht mehr nur einfach den Tester oder den Testmanager, wie es das Rollenkonzept des ISTQB vorsieht. Vielmehr finden wir Testautomatisierer, Spezialisten für Code-Analyse, Administratoren für Continuous Integration und DevOps, Last- und Performance-Experten, Spezialteams für IT-Sicherheit, etc. Diese Spezialisten übernehmen auch nicht nur Testaufgaben, sondern beraten frühzeitig konzeptionell und begleiten andere Teams in der Umsetzung als Coach [2].
Wenn diese Menschen nicht zur rechten Zeit am rechten Ort sind, dann kann das ganze Großprojekte in Schieflage bringen. So sehr es schmerzt im Agilen: Hier sind Rollen und Zuständigkeiten vorab zu klären. Daher ist die Diskussion um den Platz von Testspezialisten eine der strategisch wichtigen Herausforderungen im Großprojekt.
In SAFe gibt es Test, aber keine Tester
In dieser Frage können sogenannte Frameworks für große agile Vorhaben, wie LeSS [3] oder SAFe [1] eine sehr nützliche Rolle spielen und für’s erste eine Orientierung geben. Um es konkret zu machen, möchte ich einmal am Beispiel von SAFe die Frage klären, wo die Testkompetenz angesiedelt ist und wie die Zuständigkeit am besten vereinbart wird.
Wer in SAFe ein Testcenter, die Rolle Tester, einen Testkoordinator oder ein Test-Competence-Center sucht, wird nicht fündig. Es gibt keine Rolle für Test, auch wenn SAFe unter den agilen Organisationsframeworks sicher am ehesten Rollen für alles und jeden definiert.
Der Grund ist ganz einfach: Wenn es Profis für Qualitätssicherung gibt, wird die Verantwortung für Qualität gerne an diese abgegeben. Aber genau hier liegt eines der Schlüsselprinzipien agiler Praktiken (egal welcher Couleur): Qualität muss von Anfang an mitgedacht und ernst genommen werden.
Built-In Quality – ein Aufruf, auch im Test professionell zu sein
Built-In Quality ist einer der Core Values von SAFe, neben Transparency, Alignment und Program-Execution. Das umfasst:
- Continuous Integration
- Test First
- Refactoring
- Pair work
- Collective Ownership
- Agile Architecture
Aber wo ist hier von Testern oder Testexperten die Rede? Das kommt auf die Sichtweise an. Jedes agile Team sollte in allen sechs Praktiken kompetent sein. Doch ist es das wirklich? Vor allem, wenn etliche Teams in einem großen Ganzen zusammenarbeiten müssen? Testexperten bringen hier Kompetenzen mit, die sie in folgenden Fällen interessant machen:
- Bei Continuous Integration können Testexperten über die nötigen Stages beraten und bei der Gestaltung der Testumgebungen besonders hilfreich sein. Was wird auf welcher Integrationsstufe gebraucht? Welchen Level an Mocking brauchen wir auf welcher Stufe – vor allem teamübergreifend? Wo kommen jeweils die Daten her?
- Bei Test First kann es sich als hilfreich erweisen, dass Testexperten mit der Frage vertraut sind, wie man Features/ Stories schon frühzeitig "testen" kann. So wären da beispielsweise den Akzeptanzkriterien gleich am Anfang gekonnt Testideen gegenüber zu stellen, die im Sinne von Specification by Example [4] die Story greifbar und letztendlich verbindlich testbar machen.
- Bei Unit-Testfällen macht sich das Review durch ein gekonntes Auge von Testern immer wieder gut (Grenzwerte abgedeckt?, Entscheidungstabellen sinnvoll definiert?, ...).
- Bei Refactoring kommt das ganze Thema von Regressionstests, deren sinnvollem Umfang und der Umgang mit Testautomatisierung mit in Betracht. Hier können Testexperten gezielt beraten und bei der Umsetzung und Pflege von Regressionstestporfolien helfen. Im Zusammenhang mit dem Agile Release Train von SAFe kommen wir später noch darauf zu sprechen.
- In Bezug auf Pair Work haben sich in der Praxis nicht selten Paar-Sessions zwischen einem Entwickler und einem Tester im Team als sehr nützlich und produktiv erwiesen.
- Das Prinzip Collective Ownership spricht eher gegen Testexperten und Tester. Hier kommt es stark darauf an, dass Tests von allen verstanden werden (können) und nicht als das Alleinstellungsmerkmal von selbsternannten Testexperten missbraucht werden.
- Die Agile Architecture kann übrigens auch von Testexperten profitieren, die darauf achten, dass es immer etwas wirklich Testbares gibt. Das Prinzip #1 (Design Emerges. Architecture Is a Collaboration) könnte gut durch die Sichtweise von Testern unterstützt werden, da sie einen guten Blick darauf haben, was am Ende (jeweils) sichtbar und lauffähig sein muss. Wichtig sind Tester als Advokaten des Prinzips #5 (They Build It. They Test It). Gerade in großen Projekten oder Programmen kann es nicht genug Menschen geben, die rasch etwas Lauffähiges einfordern.
Zu guter Letzt definiert der SAFe (Core Value Built-In Quality) ein gut funktionierendes Qualitätsmanagement, dass vor allem die Compliance (zu welchen Standards und Vorgaben auch immer) in den Vordergrund stellt. In der IT ist kaum noch ein Vorhaben frei von gesetzlichen, vertraglichen oder branchenüblichen Vorgaben, die bitte auch tunlichst eingehalten werden sollten. Tester und Testexperten sind zwar keine Qualitätsmanager, aber sie sind eine wichtige Instanz, um die erforderlichen Vorgaben frühzeitig zu konkretisieren und deren Einhaltung am Ende nachzuweisen.
Es gibt Tester im agilen Team und Testexperten im Systemteam
An dieser Stelle mag sich schon der eine oder andere fragen, ob ich wirklich von den Testern rede, denen man so im Projektalltag begegnet? Nein – und doch wieder ja. Ohne entsprechende Weiterentwicklung wird ein "traditioneller" Tester nicht erfolgreich im agilen Umfeld unterstützen können [2]. Darin unterscheidet er sich aber auch nicht wirklich von seinen Kollegen in der Analyse oder in der Entwicklung. Seine Erfahrung, seine Tester-Perspektive und seine Spezialisierung (z. B. Testautomatisierung, Testumgebungen, Last- und Performancetests, Sicherheit, ...) machen ihn aber wertvoll. Daher reden viele inzwischen lieber von Testexperten oder englisch Test Professionals, um diese Kombination aus Perspektive und Spezialisierung anzudeuten.
Aber wo sind diese Testexperten organisatorisch anzusiedeln? Selbstorganisierende Teams finden hier sicher eine Lösung. Aber selbstorganisierende Großprojekte sind da wohl eher nicht zu erwarten. Aus meiner Sicht gibt es für Testexperten in agilen Großprojekten, die nach SAFe orientiert arbeiten, genau zwei signifikante Stellen:
- Tester im Team – Dies ist eher ein Universalist in Bezug auf Analyse, Entwicklung und Test, der sich aber vom Schwerpunkt her mit allen Aspekten des Tests im agilen Team beschäftigt. Bei Kanban mag es sogar explizit der Tester sein. In anderen Teams kristallisiert sich über die Zeit eventuell ein Teammitglied heraus, dass für Tests ein besonderes Auge und Händchen hat oder sich hier besonders fortgebildet hat.
- Testexperte im Systemteam – Hierbei handelt es sich um stark spezialisierte Testexperten, die als Coach, spezielle Einsatzgruppe oder Service für die agilen Teams in Erscheinung treten. Ihre Aufgabe ist es, alle Testaspekte sinnvoll voranzutreiben, die teamübergreifend gelöst werden müssen (Werkzeugeinsatz, E2E-Tests, Testautomatisierungstechniken, Testumgebungen, Testdaten, ...).
Das Systemteam ist kein Testteam oder Testcenter
Gerade die zweite Gruppe ist in vielen Projekten derzeit nur unzureichend ausgeprägt und wird gerne missverstanden. Teamübergreifend dürfen Testexperten nie den Dienstleistungsgedanken gegenüber den agilen Teams vergessen: Die Teams selbst müssen verantwortlich für die Qualität bleiben! Sie dürfen daher aber auch gezielt mit Unterstützung von Experten, mit reifen Praktiken und mit erprobten Technologien/ Werkzeugen rechnen. Die klassischen Test Competence Center haben hier ausgedient. Bevormundung sollte die absolute Ausnahme bleiben. SAFe empfiehlt hier einen Kompromiss, bei dem die Velocity des gesamten Agile Release Trains (also das Ergebnis aller Teams) das Maß für den optimalen Mix ist. Warum aber findet sich diese Gruppe eher im Systemteam von SAFe wieder?
Werfen wir dazu ein Blick auf die Aufgaben des Systemteams:
- Building Development Infrastructure – Hier geht es u. a. auch um den Aufbau von Continuous Integration und möglichst auch Continuous Deployment. In solchen Fällen braucht es Experten, die sich gut mit den erforderlichen Testumgebungen und verschiedenen Integrationsstufen auskennen. Zudem müssen automatisierte Regressionstest-Suiten in solche Integrations- und Lieferprozesse eingebunden werden.
- System Integration – In komplexeren Umfeldern kommt es darauf an, frühzeitige bilaterale API-/ Schnittstellentests zwischen verschiedenen Systemen und damit agilen Teams zu organisieren. Testexperten können Strategien entwickeln, systematisch diese Teilstrecken von End-To-End-Prozessen zu testen.
- End-to-End- and Solution Performance Testing – Vor allem im Bereich von End-to-End-Prozessen und teamübergreifenden Tests sind Testexperten sehr wichtig. In großen Projekten hat es sich für mich immer als sehr nützlich erwiesen, die Einzeltests in den Teams immer von einem teamübergreifenden Gesamtszenario her zu denken. Die Tests in den Teams haben damit immer eine klare Vision bis zum Abschluss eines Programm-Inkrements (PI) in SAFe (ca. 10 Sprints). Für Last- und Performancetests braucht es meist sowieso spezialisierte Tester, die gezielt regelmäßige Messungen durchführen und so den agilen Teams Hinweise für eigene kleinere Performancemessungen in der täglichen Arbeit geben
- System- and Solution-Demos – SAFe erwartet nach jedem Sprint eine aussagekräftige System-Demo – einen Testlauf der möglichst immer eine teil-integrierte Lösung zeigt. Wie teil-integriert diese Lösung ist, muss nach bestem Ermessen immer wieder neu festgelegt werden. Testexperten können hier sehr wirksam auf einen frühzeitigen integrierten Testlauf hin wirken. Sie wissen, wie man Teilstrecken testet und wie viel an Mocking in frühen Phasen statthaft ist. Wenn bereits zum PI-Planning (oder kurz danach) eine Vision von End-To-End-Tests für die Gesamtlösung entwickelt wird, lässt sich daraus rasch und gezielt auf eine erfolgreiche Solution-Demo hin arbeiten. Auch hier bewährt sich die gute konzeptionelle Arbeit von Testexperten.
- Release – Testexperten sollten sich i. d. R. gut mit gezielten Testberichten auskennen, die die verschiedenen Stakeholder über den Stand von Produktfortschritt und -qualität informieren. Diese sind bei Release-Entscheidungen unerlässlich, um ggf. Risiken für den Produktivgang sinnvoll einschätzen zu können. Außerdem hilft ein guter Blick auf die Gesamtlösung und damit auf die aggregierten Testergebnisse aus der Solution-Demo. Ohne gute Werkzeugunterstützung im Test wird das schwierig. Daher kommt Testexperten auch eine starke Beratungsaufgabe im Werkzeugeinsatz zu.
Bei kaum einer anderen Instanz in SAFe lassen sich die Aufgaben von Testexperten so stark mit den Rollenaufgaben in Einklang bringen, wie beim Systemteam. Aber soll das Systemteam dann ganz aus Testexperten bestehen? Sicher nicht! Wichtig ist gerade bei den oben geschilderten Aufgaben, dass hier mehrere Disziplinen konstruktiv zusammenarbeiten. Was ist ein Testexperte ohne einen erfahrenen Entwickler, der schon viele Integrationssysteme gebaut hat, ohne einen erfahrenen Systemarchitekt, der die Ausgestaltung der Testumgebungen gut beurteilen kann? Wie sollen Schwachstellen in der Performance gezielt gemessen werden, wenn die technischen Schwachstellen im System nicht erkannt werden. Wie soll man Produktivgänge begleiten, wenn niemand weiß, wie diese im Rechenzentrum zu bewerkstelligen sind.
Dass das Systemteam nur aus Testern besteht, die alle anderen Kompetenzen den agilen Teams, bürokratisch agierenden Rechenzentren oder schlicht nicht verfügbaren Systemarchitekten sprichwörtlich aus der Nase ziehen müssen, ist sicher keine gute Idee! Das Systemteam besteht aus einer Menge unterschiedlicher Spezialisten, die aber gelernt haben, zusammenzuarbeiten und sich als Service für agile Teams verstehen.
Halte den Zug am laufen, aber bringe den Flieger rechtzeitig auf den Boden
Letztendlich ist der Platz von Testern oder Testexperten in SAFe überall dort, wo es darum geht, den Agile Release Train am Laufen zu halten. Das ist ja wirklich keine Selbstverständlichkeit bei komplexen Lösungen mit vielen Beteiligten. Überall dort, wo es gilt, den Fortschritt in Form laufender Software und funktionierender Lösungen regelmäßig (z. B. in der System Demo oder im Continuous Deployment) nachzuweisen, sollten Tester sich engagieren. Sei es in den einzelnen Teams als Fürsprecher für das professionelle Testen oder als beratender und unterstützender Testexperte im Systemteam.
Für Tester in SAFe gilt
- konzipiere und plane Testumgebungen möglichst früh – skaliere sie auch nach Bedarf (Cloud-Services, Docker-Container, etc.),
- baue Testdatenbestände möglichst früh – auch wenn es noch schwer fällt, fördere kontinuierliches Testen auch teamübergreifend – immer mit Beteiligung der Teams und stets auch (teil-)automatisiert,
- denke Tests immer erst gemeinsam aus End-To-End-Perspektive und verfeinere dann in den Teams und
- halte das Ziel des Programm-Inkrements stets im Auge und mache es früh testbar.
Wichtig ist, dass sowohl im agilen Team, als auch im Systemteam immer interdisziplinär gearbeitet wird und Testexperten sich konstruktiv einbringen. Wichtig ist auch, dass die Verantwortung für Qualität in den agilen Teams bleibt, die Qualitätssicherung aber teamübergreifend sinnvoll organisiert und als überzeugende Dienstleistung den agilen Teams verfügbar gemacht wird.
Große Projekte und Programme scheitern meist daran, dass zu lange nichts wirklich Überprüfbares erzeugt und bewertet wird, dass zu lange die Gesamtlösung eher Theorie bleibt und nach einem euphorischen Höhenflug am Ende der Flieger nicht mehr rechtzeitig auf den Boden gebracht wird. Testexperten können genau hier einwirken, frühzeitig die Programm-Inkremente testbar zu machen, so dass einer geeigneten Landung nichts mehr im Weg steht.
- Scaled Agile Framework – SAFe
- M. Klonk, 2018: Was heute einen guten Tester in der IT ausmacht. In: OBJEKTSpektrum (02/2018), S. 22–26
- Large-Scale Scrum – LeSS
- G. Adzic, 2011: Specification by Example. Manning Publications
