Funktionsübergreifende Teams in agilen Teams sind Gruppen, in denen jedes Mitglied über tiefgreifende Spezialkenntnisse verfügt und diese nutzt, um das Team über seine Kernaufgabe hinaus zu unterstützen. Das Risiko ist Breite ohne Tiefe: Wenn von jedem erwartet wird, dass er alles macht, macht niemand etwas gut. Qualität bleibt nur dann eine gemeinsame Verantwortung, wenn jeder seinen spezifischen Beitrag dazu versteht.
Das Wichtigste in Kürze
- Wenn jeder für die Qualität verantwortlich ist, ohne dass ein Verantwortlicher benannt wird, übernimmt niemand die Verantwortung, und den meisten agilen Teams fehlt die Kompetenz zum Testen, um diese Verantwortung gemeinsam zu tragen.
- Breite Kompetenzprofile, die so genannte Kammform, führen zu einer flachen Expertise in der Breite; zwei oder drei tiefe Kompetenzen pro Person sind die realistische Obergrenze für echte Spitzenleistungen.
- Das Review von KI-generierten Tests ohne Kenntnis der Testentwürfe bringt keinen Mehrwert, weil man nicht erkennen kann, was falsch ist oder fehlt, wenn man nicht weiß, wie die korrekte Ausgabe aussehen sollte.
- Der Testkontext bestimmt den Beitrag des Testers: Jemand, der keinen technischen Hintergrund hat, liefert den größten Wert im vorgelagerten Bereich, indem er Akzeptanzkriterien und Prozessmodelle formt, und nicht im nachgelagerten Bereich der Pipeline.
Mechanische Agilität bricht das funktionsübergreifende Team, bevor es beginnt
Viele Unternehmen übernehmen agil, indem sie die Oberfläche kopieren und den Grund überspringen. Sie lesen einen Teil des Scrum-Leitfadens, installieren ein paar Rollen und Zeremonien und nennen das Ergebnis dann agil. Gitte Ottosen nennt das mechanisch agil, und das ist der Punkt, an dem funktionsübergreifende Teams zu scheitern beginnen.
Der Tipp ist einfach. Frag einen Scrum Master oder sogar einige Coaches, was im Agilen Manifest steht oder was die zwölf Prinzipien sind. Oft können sie nicht antworten. Dieses Wissen ist die Grundlage für ein funktionsübergreifendes Team, denn es erklärt, warum das Team so arbeitet, wie es arbeitet.
Es gibt einen Unterschied zwischen agilem Handeln und agilem Sein. Beim agilen Handeln wird die Methode als ein Hack behandelt, den man anschraubt. Agil zu sein bedeutet, dass das Team den Zweck hinter der Methode versteht und danach handelt.
Was Scrum eigentlich über ein “Entwicklerteam” sagt
Scrum sagt nicht, dass Tester unnötig sind. Der Scrum-Leitfaden verwendet den Begriff “Entwicklerteam”, aber ein Entwickler in diesem Sinne ist jedes Teammitglied mit Spezialwissen, das die Fähigkeit des Teams unterstützt, Werte zu liefern. Dazu gehören auch Tester, Business-Analysten und andere.
Diese Fehlinterpretation hat reale Konsequenzen. Gitte hat erlebt, dass Unternehmen ihre Testmanager und Tester mit der Begründung entlassen haben, Scrum verlange ein Entwicklerteam und Entwickler sollten jetzt alles machen. Diese Entscheidung beruht auf einem aus dem Zusammenhang gerissenen Begriff.
Die Aufgabe eines Teammitglieds ist es, mit seinen Fähigkeiten zur Wertschöpfung beizutragen. Das Testen ist eine dieser Spezialitäten und keine Aufgabe, die verschwindet, wenn sich das Organigramm ändert.
Quality Engineering ist eine starke Idee, die für eine Welt entwickelt wurde, in der nur wenige Teams leben
Qualitäts-Engineering als gemeinsame Denkweise, bei der das ganze Team für die Qualität verantwortlich ist, ist erstrebenswert. Das Ziel ist ein leistungsfähiges Team, das die volle Verantwortung übernimmt und die Kompetenz hat, gut zu testen. Das Problem ist die Kluft zwischen diesem Ziel und den meisten realen Teams.
Den meisten agilen Teams fehlt die Kompetenz zum Testen, um dies zu erreichen. Wenn Qualitätstechniken zu allem anderen, was ein Team bereits tut, hinzukommen, ohne dass jemand über die entsprechenden Fähigkeiten verfügt, wird das Ergebnis schlechter, nicht besser. Die Denkweise ist gut. Aber es fehlt die Reife.
“Qualität ist ein Wert für jemanden, der irgendwann einmal wichtig wird.” Diese Definition, die Gitte Jerry Weinberg zuschreibt und die von James Bach und Michael Bolton erweitert wurde, gibt der Arbeit ein Ziel: die Menschen zu befunden, auf die es ankommt, und den Wert zur richtigen Zeit zu liefern.
Wir müssen uns nur daran erinnern, dass die meisten von uns nicht in einer perfekten Welt leben. Wir leben in der realen Welt. Wir leben nicht in der Welt der Einhörner.
- Gitte Ottosen
Warum “jeder verantwortlich ist” bedeuten kann, dass niemand verantwortlich ist
Wenn jeder für etwas verantwortlich ist, kann sich die Verantwortung auflösen. Manche Teams nehmen die kollektive Verantwortung ernst. Viele tun das nicht, und die Qualität schlüpft durch die Ritzen zwischen den Rollen.
Für die meisten Entwickler/innen ist das Testen über die Unit- und Unit-Integrationsstufe hinaus nicht ihre Leidenschaft. Sie haben ihren Beruf gewählt, um Software zu entwickeln, nicht um sie auf breiter Ebene zu testen. Das ist kein Makel, sondern liegt an ihren Fähigkeiten und Interessen.
Es gibt auch Menschen, die das Testen lieben. Besser ist es, die Teammitglieder dort arbeiten zu lassen, wo ihre Leidenschaft liegt, denn aus Leidenschaft entstehen Fähigkeiten. Jemanden zu einer Arbeit zu zwingen, die ihn nicht interessiert, führt nicht zu guten Ergebnissen. Entwicklerinnen und Entwickler sollten trotzdem testen, aber sie brauchen die nötigen Fähigkeiten und jemanden, der sie beim Aufbau dieser Fähigkeiten unterstützt.
Ein Team, das sich zu breit aufstellt, ist zu nichts zu gebrauchen
Die Verschiebung von I-förmigen zu T-förmigen Spezialisten hat sich immer weiter ausgedehnt. Aus der T-Form wurden die Pi-Form und die M-Form, drei tiefe Kompetenzen, was immer noch praktikabel ist. Dann kam die Rede von kammförmigen Menschen, mit vielen Zähnen und jedem Zahn kurz.
Dieses Bild trägt die Warnung in sich. Ein Kamm hat viele Fähigkeiten und keine Tiefe. Wenn von jedem erwartet wird, alles zu tun, kann niemand etwas wirklich gut.
Der Druck liegt nicht nur auf den Testern. Entwickler/innen tragen die Werkzeuge, die Pipeline und die kognitive Last der gesamten Lieferkette. Gitte verweist auf eine Zeichnung des Cartoonisten Comic Agile mit dem Titel “The Agile Team’s Cognitive Overload” (Die kognitive Überlastung des agilen Teams), die zeigt, wie weit die Last verteilt ist.
Strebe eine N- oder M-Form an: zwei oder drei Bereiche mit echter Tiefe, plus die Fähigkeit, Teammitglieder außerhalb deines Kerns zu unterstützen. Das ist es, was Scrum beschreibt, und es ist besser, als sich zu verzetteln.
Wie ein Tester einen Mehrwert schafft, wenn das klassische Testen vom Tisch ist
Finde heraus, wo dein Wert im Verhältnis zum erbrachten Wert liegt, und arbeite dann dort. Die Antwort ist kontextabhängig, nicht festgelegt und ändert sich mit dem Team und dem Projekt.
Ein Tester ohne technischen Hintergrund kann keine Unit Tests reviewen oder die Pipeline unterstützen. Derselbe Tester kann dem Product Owner helfen, gute Akzeptanzkriterien zu schreiben, Funktionsbeschreibungen zu reviewen und die Aufnahme von Anforderungen zu verstärken. Der Wert rückt an die Spitze des Entwicklungsmodells, bevor der Code existiert.
Ein Tester mit technischem Hintergrund kann Testautomatisierung betreiben, Unit- und Unit-Integrationstests unterstützen und bei der Entwicklung der Pipeline helfen, während er gleichzeitig Testentwurfsverfahren und explorative Tests einbringt. Gleiche Rolle, unterschiedlicher Beitrag, geprägt von Fähigkeiten.
Auf der Kundenseite eines Projekts, wo eine harte Grenze zwischen dir und den Entwicklern des Anbieters verläuft, liegt der Wert auf dem Geschäft. Du stellst Arbeitsabläufe dar, zeichnest Prozessdiagramme und nutzt sie, um zu testen und den Entwicklern beizubringen, was das System tun soll. Tester verstehen den Verwendungszweck eines Systems oft besser als jeder andere.
Wo man anfängt: das Fundament reparieren, bevor man höher hinaus will
Du kannst nicht alles auf einmal in Ordnung bringen, also fang mit Unit- und Unit-Integrationstests von vorne an. Wenn das Team dort reift, kannst du deinen Schwerpunkt auf andere Bereiche verlagern.
Ein Tester kann das vorantreiben, ohne Code zu schreiben. Du kannst das strukturierte Testen erklären, den Entwicklern bei der Entscheidung helfen, was getestet werden soll, und sicherstellen, dass die Werkzeuge das unterstützen, was sie tun müssen. Verbringe eine gewisse Zeit damit, die Reife der Entwickler/innen zu stärken, und konzentriere dich dann auf die Arbeit, die nur ein/e Tester/in gut machen kann.
Die Ausgangssituation in der Praxis ist selten sauber. User-Stories und Funktionsbeschreibungen sind oft mangelhaft oder fehlen, Akzeptanzkriterien sind nicht vorhanden, und manche Entwickler haben jahrzehntelang nie mit dem Testen gearbeitet und kein Interesse daran, damit anzufangen. Erfasse zuerst deinen Kontext und entscheide dann, wo du anfangen willst.
Zwei Mappings, die die Verantwortung für die Qualität in die Hände des Teams legen
Der Newsroom-Ansatz bietet zwei Workshop-Tools für die kontinuierliche Verbesserung: Qualität-zu-Tätigkeit-Mapping und Qualität-zu-Menschen-Mapping. Beide machen den Anteil der einzelnen Teammitglieder an der Qualität sichtbar.
Für die Zuordnung der Qualität zu den Mitarbeitern führst du einen Workshop mit sechs Schlüsselbereichen durch, darunter Qualitätsbewusstsein, Automatisierung und Infrastruktur. Setze diese Bereiche in die erste Spalte einer Matrix und die Teamrollen in die oberste: Entwickler, Tester, Business Analysten und andere. Jeder macht sich Gedanken über seinen Anteil in jedem Bereich und darüber, was er dazu beitragen kann.
Sobald sich die Tafel mit Klebezetteln füllt, setzt das Team Prioritäten, denn nicht alles lässt sich auf einmal verbessern. Du kannst die Prioritäten nach Personen oder nach den DevOps-Aktivitäten setzen, bei denen Qualität wichtig ist.
Der Punkt ist die Eigenverantwortung. Die Verbesserung wird nicht von außen reingedrückt. Sie weckt das Bewusstsein im Team und zeigt den Mitgliedern, dass sie einen Beitrag leisten können. Außerdem wird der Reflex durchbrochen, dass Qualität nur mit Testen gleichgesetzt wird, obwohl Qualitätssicherung, Qualitätssteuerung und Testen zwei verschiedene Dinge sind.
KI verlagert die Arbeit, aber nur Können macht die Verlagerung sicher
KI kann User-Stories reviewen, Akzeptanzkriterien aufstellen und Gherkin-Szenarien erstellen. Es braucht immer noch einen Menschen mit Urteilsvermögen, um zu prüfen, ob die Ergebnisse richtig sind. Kritisches Denken ist die Fähigkeit, die hier am wichtigsten ist.
Es gibt einen Widerspruch, der es wert ist, benannt zu werden. In Berichten wird eine Zukunft beschrieben, in der Tester als Gutachter und Torwächter von KI-Ergebnissen fungieren, während die gemessene Kompetenzstufe von Testern und Testerinnen sinkt. Du kannst das Tor nicht bewachen, wenn du nicht weißt, wie gutes Testen aussieht.
Testentwurfsverfahren klingen altmodisch und bleiben doch unverzichtbar. Ein Review von KI-generierten Testfällen, ohne die zugrundeliegende Technik zu verstehen, bringt nichts, denn du kannst nicht sagen, ob das Ergebnis gut ist. Gitte hat Basic ChatGPT dabei erwischt, wie es für eine einfache Anfrage viel zu viele Testfälle erzeugt hat, weil sie das Verfahren gut genug kannte, um die Fehlhandlung zu erkennen.
Testen schafft Vertrauen. Um den Stakeholdern die Gewissheit zu geben, dass das, was geliefert wird, sicher ist und den erwarteten Wert liefert, muss das Team in der Lage sein, zu überprüfen, ob die Anforderung richtig interpretiert wurde und ob die KI dieser Richtung gefolgt ist.
Was ein Tester lernen sollte, um wertvoll zu bleiben
Entwickle Tiefe, nicht Breite. Eine Handvoll oder zwei Testentwurfsverfahren, die du so gut verstehst, dass du sie täglich anwenden und erkennen kannst, wenn die KI etwas Falsches ausgibt, sind die Basis.
Die vollständige Liste, die Gitte empfiehlt:
- Techniken für den Testentwurf. Du solltest sie so gut kennen, dass du sie täglich anwenden und die von der KI erstellten Tests an deinen Erwartungen messen kannst.
- Exploratives Testen. Viele behaupten, es zu tun, und führen tatsächlich ad-hoc-Tests durch. Exploratives Testen ist immer noch strukturiert und nutzt kritisches Denken und Testentwurfsverfahren. Es wird nur nicht in geskripteten Testfällen dokumentiert.
- Testentwurf für Anforderungen. Nutze Techniken, um von einer Prozesszeichnung zu Tests zu gelangen, damit die Überdeckung ausreichend ist, weder zu wenig noch zu viel.
- Risikobasiertes Testen. Viele sagen, dass sie es tun, aber nur wenige tun es. Eine Risikoanalyse des Produktrisikos oder des Qualitätsrisikos ist nur der Anfang. Der schwierigere Schritt besteht darin, diese Analyse in die effektivsten Tests umzuwandeln, da Teams oft zu viel oder die falschen Dinge zu viel testen.
- Prompting. Nutze ChatGPT, Copilot und ähnliche Tools als Unterstützung, nicht als Ersatz. Verstehe, wo sie stark sind und wo nicht, und kopiere niemals unkritisch die Ergebnisse.
Du brauchst vielleicht keinen weiteren Kurs. Lies dir das Material, das du bereits hast, noch einmal durch, suche dir Videos oder E-Learning, setze dich dann mit einem Kollegen über echte Unterlagen und frage, welche Technik passt. Ausprobieren ist der schnellste Weg zum Lernen. Lernen, das nie in der Praxis angewendet wird, ist verschwendet.
