ACT2LEAD ist ein Führungsmodell für den Softwaretest mit acht Prinzipien: Testen überall mitdenken, Entscheidungen nach Kontext, Transparenz über die Qualität, zwei Säulen aus Automatisierung und Menschen, Lernen durch Testen, eine Qualitätskultur ermöglichen, am Risiko ausrichten und Vielfalt der Ansätze. Das Modell verlangt, dass Testen auf Ebene der Organisation aktiv geführt wird, statt es allein den einzelnen Teams zu überlassen.
Das Wichtigste in Kürze
- In den meisten Unternehmen fehlt Führung im Testen: Das Management weiß, dass getestet werden muss, kann aber nicht erklären, was dazugehört, anders als bei Entwicklung oder Architektur.
- Das Modell ACT2LEAD gliedert Führung im Testen in acht Bereiche: Testen überall mitdenken, Kontext, Transparenz, Automatisierung und Menschen, Lernen, Qualitätskultur ermöglichen, am Risiko ausrichten und Vielfalt.
- Eine Qualitätskultur zu ermöglichen (das E in ACT2LEAD) heißt für Führungskräfte, ständig über Testen und Qualität zu sprechen, statt die Verantwortung komplett an die Entwicklungsteams abzugeben.
- Große Organisationen brauchen eine eigene Testleitung, etwa einen Head of Testing, der Mindeststandards für alle Teams setzt. Autonome Teams, die jeweils auf ihre eigene Art testen, reichen in dieser Größe nicht aus.
- Gutes Testen braucht Vielfalt bei Techniken, Menschen, Ansätzen und Umgebungen, weil kein einzelnes Werkzeug und kein einzelnes Verfahren alle Blickwinkel abdeckt, die ein komplexes Softwareprodukt verlangt.
Warum dem Softwaretest oft ein Testleiter fehlt
Die meisten Unternehmen organisieren das Testen auf Teamebene, aber kaum jemand führt es. Es fehlt ein Testleiter im eigentlichen Sinn. Die Teams planen ihre Arbeit, führen ihre Tests durch und organisieren sich selbst, und an der Basis klappt das oft gut. Was fehlt, sitzt eine Etage höher: jemand, der die Bedingungen für gute Qualität schafft und eine Kultur aufbaut, in der gutes Testen möglich ist.
Kari Kakkonen hat dieses Muster in seiner Laufbahn immer wieder gesehen. Wer in einer Organisation weit genug nach oben schaut, trifft auf Leute, die wissen, dass getestet werden muss, aber nicht sagen können, was das eigentlich bedeutet. Vielleicht schreiben sie “Es muss getestet werden” in eine Anforderung und lassen den Satz dann unbesehen stehen.
Die Lücke wird sichtbar, wenn du zwei Fragen vergleichst. Frag einen CTO, was die Entwickler machen, und die Antwort ist präzise: Sie schreiben Code, hier in Python, dort in C, woanders in Java, und sie kümmern sich um die Architektur. Frag dieselbe Person, was die Tester machen, und die Antwort wird dünn: “Ich nehme an, die machen Testautomatisierung und ein paar Prüfungen.” Diese Unschärfe ist das Symptom für fehlendes Wissen über das Testen.
Wer Testen versteht, kann es auch führen
Führung im Testen setzt Verständnis voraus. Du musst nicht jedes Verfahren im Detail kennen. Du brauchst aber genug, um dort mitzureden, wo Unternehmensführung, die Beauftragung von Software und deren Entwicklung und Test zusammenkommen.
Das ist das Kernargument hinter dem Modell ACT2LEAD (gesprochen “ACT to LEAD”), das Kari mit seinem Co-Autor Marko Rytkönen entwickelt hat. Der Name ist eine Merkhilfe: acht Zeichen, jedes steht für ein Prinzip. Das Modell ist so gebaut, dass man es sich merkt und umsetzt, statt es in die Schublade zu legen. Es soll das Testen im ganzen Unternehmen auf die Tagesordnung bringen, nicht nur in den Arbeitsalltag der Tester.
Von einer Führungskraft erwartet niemand, dass sie selbst Tests durchführt. Erwartet wird, dass sie immer wieder über Testen und Qualität spricht und nicht zulässt, dass das Thema zur Privatangelegenheit eines einzelnen Teams wird.
Die acht Prinzipien von ACT2LEAD
ACT2LEAD trägt das Denken ans Testen in Budgetplanung, Lieferantenauswahl, Betrieb und Teamkultur, statt es auf den Moment zu beschränken, in dem Code geliefert wird. Jedes Zeichen steht für ein Arbeitsprinzip.
| Zeichen | Prinzip | Was es bedeutet |
|---|---|---|
| A | Add testing to everything | Testen schon bei der Budgetplanung, der Wahl des Lieferanten und dem Betrieb in Produktion mitdenken, nicht erst, wenn der Code zum Prüfen bereitliegt. |
| C | Context | Testen unterscheidet sich je nach Geschäft, Domäne, Technologie, Team, Budget und Zeitdruck. Das Vorgehen passt sich dem Kontext an. |
| T | Transparency | Testen sichtbar machen: teilen, was du tust, was du findest und wo die Qualität schwach ist, damit andere helfen können. |
| 2 | Two: Automatisierung und Menschen | Es braucht beides. Automatisierung und Pipelines wachsen weiter, menschliche Kreativität und exploratives Testen bleiben trotzdem nötig. |
| L | Learning | Testen, um zu lernen, wie die Software funktioniert, und lernen, besser zu testen. Beide Richtungen zählen. |
| E | Enable | Die Bedingungen schaffen, unter denen gutes Testen möglich ist und eine Qualitätskultur trägt. |
| A | Adapt to risks | Mehr testen, wo das Risiko höher ist. |
| D | Diversity | Viele Techniken, Ansätze, Menschen, Lieferanten und Umgebungen nutzen. |
Teste alles, nicht nur den Code
Testen beginnt lange bevor es Code gibt. Es gehört in die Budgetdiskussion, in die Entscheidung, welcher Lieferant oder Dienstleister deine Software baut, und in die Planung, wie du das Produkt in Produktion betreiben willst.
In jedem dieser Momente steckt eine Testfrage. Wie stelle ich sicher, dass das funktioniert? Wie prüfe ich es in Produktion? Wie bestätige ich, dass es wirklich tut, was es soll? Wer Testen als Phase sieht, die mit der Code-Lieferung beginnt, verpasst die meisten Stellen, an denen nachgedacht werden muss.
Der Kontext entscheidet, wie gutes Testen aussieht
Testen ist nicht überall gleich. Das richtige Vorgehen hängt vom Geschäft ab, von der Domäne, der Technologie, dem Team, dem Budget und davon, wie eilig es ist.
Kontextgetriebenes Testen heißt, die Methoden an diese Bedingungen anzupassen, statt ein festes Regelwerk abzuarbeiten. Es gibt keine universell beste Technik, die nur darauf wartet, ausgewählt zu werden. Was in einem Umfeld funktioniert, kann in einem anderen falsch sein.
Warum Transparenz besser ist als blindes Vertrauen in Lieferanten
Transparenz heißt, sichtbar zu testen und Informationen breit zu teilen, statt stillschweigend darauf zu vertrauen, dass die anderen ihren Teil erledigen. Wenn du Fehler oder Qualitätsprobleme findest und offenlegst, können sich alle einbringen.
Das Risiko wächst, wenn mehrere Beteiligte, Dienstleister oder Zulieferer zusammenarbeiten. Grenzen entstehen schnell. Jede Partei liefert ihr Stück, ein Vertrag regelt, wer was testet, und der Rest verschwindet hinter einem “Da vertrauen wir denen einfach.” Transparenz ersetzt blindes Vertrauen durch Sichtbarkeit: was du forderst, was du bekommst und was tatsächlich passiert.
Sichtbarkeit heißt nicht, alle mit Daten zu überschütten. Wer jede Metrik und jeden Fehler weiterreicht, erzeugt eine Informationsflut und verfehlt das Ziel. Die Arbeit besteht darin, Informationen zu verdichten, auf das jeweilige Publikum zuzuschneiden und Dashboards zu bauen, auf denen sich die Qualität leicht ablesen lässt, ohne dass etwas versteckt wird.
Du brauchst immer Automatisierung und Menschen
Testen braucht beides, Automatisierung und Menschen, nie das eine statt des anderen. Der Sog Richtung Automatisierung hält an: mehr Testautomatisierung, mehr Automatisierung in der Auslieferung, mehr CI/CD-Pipelines. Das ist nützlich, reicht aber nicht.
Menschliche Tester bringen Erkundung, Kreativität und neue Ideen ein, die keine Automatisierung hervorbringt. Deine Aufgabe ist es, beides in deinen Kontext einzubauen, denn jede Seite deckt ab, was die andere nicht kann.
Tester kennen die Software besser als alle anderen
Wenn dir jemand erklären soll, wie eine Software funktioniert, frag den Tester. Tester haben eher Breite als Spezialwissen in einer Nische. Sie lernen das ganze Produkt kennen: wo jedes Teil hingehört, wie es sich verhalten sollte und wie es sich tatsächlich verhält.
Diese Breite kommt aus der Arbeit selbst. Ein Tester braucht das Gesamtbild, weil er die Software aus vielen Blickwinkeln und gegen viele Risiken prüft. Das Lernen läuft in beide Richtungen: Du testest, um das System kennenzulernen, und lernst dabei, es besser zu testen.
“Wenn du wissen willst, wie diese Software funktioniert und worum es bei ihr eigentlich geht, dann solltest du den Tester fragen, denn der hat das Gesamtbild.”
(Kari Kakkonen)
Eine Qualitätskultur zu ermöglichen ist die eigentliche Führungsaufgabe
Das wichtigste Prinzip ist Enable, das Ermöglichen: Bedingungen schaffen, unter denen gutes Testen stattfindet. Mach gutes Testen zur Erwartung. Mach es normal, über Probleme und Fehler zu sprechen, aus ihnen zu lernen und niemandem die Schuld dafür zuzuschieben.
Dafür braucht es vor allem Wiederholung von oben. Je höher du in einem Unternehmen sitzt, desto wichtiger ist es, dass du Testen und Qualität immer wieder als etwas benennst, das zählt. Ein CEO wird nicht selbst testen, aber er kann dafür sorgen, dass Qualität Thema bleibt, statt sie als einsame Pflicht an ein Team weiterzureichen.
Für viele Unternehmen ist das ein echter Kulturwandel. Der bequeme Weg ist, zu sagen: “Wir haben ein paar Tester, die machen halt ihr Ding”, und zur Tagesordnung überzugehen. Mit dieser Gewohnheit zu brechen, ist die Veränderung, die sich lohnt.
Am Risiko ausrichten und vielfältig testen
Richte dein Testen am Risiko aus. Bereiche mit hohem Risiko bekommen mehr Aufmerksamkeit und mehr Tests. Das Prinzip ist einfach, und wer es anwendet, steckt den Aufwand dorthin, wo er am meisten bringt.
Gleich nach dem Ermöglichen kommt die Vielfalt. Nutze mehrere Techniken, mehrere Menschen, mehrere Ansätze, mehrere Lieferanten, mehrere Umgebungen. Unterschiedliche Blickwinkel stützen sich gegenseitig und sorgen zusammen für bessere Qualität.
Führungskräfte fragen oft reflexhaft nach der einen besten Lösung: dem besten Werkzeug, dem besten Vorgehen, Automatisierung für alles. Qualität entsteht aber nicht aus einem einzigen Blickwinkel. Stell dir eine Taschenlampe in einer Höhle vor. Richtest du sie auf eine Stelle, siehst du diese Stelle, nicht die Höhle. Um das Ganze zu sehen, brauchst du mehrere Perspektiven.
Was ein Testleiter in einem großen Unternehmen tut
Große Unternehmen brauchen eine Rolle, die für das Testen verantwortlich ist, etwa einen Head of Testing. Oft ist der CTO ein ehemaliger Architekt, Entwickler oder kommt aus dem Business. Das ist in Ordnung, aber irgendwer muss dafür sorgen, dass im ganzen Produkt getestet wird.
Autonome, selbstorganisierte Teams sind wertvoll, und Kari unterstützt sie. Wenn aber jedes Team auf seine eigene Art testet, reicht das in großem Maßstab nicht. Beim Testleiter geht es nicht darum, im Sinne von Kontrolle “das Sagen” zu haben. Es geht darum, sicherzustellen, dass überall dort getestet wird, wo Software entsteht.
Die praktischen Werkzeuge sind schlank. Leg allgemeine Testrichtlinien fest, die ein Minimum vorgeben, statt jedem Team dieselben Regeln zu diktieren: Macht mindestens so viel, und findet dann die Wege, die zu eurem Team und eurem Kontext passen. Unterstütze das mit Test-Communities, in denen Menschen Ideen austauschen. Es heißt bewusst Testen und nicht Tester, denn am Testen kann sich jeder beteiligen.
Ein Führungshandbuch aus Fragen
ACT2LEAD ist vollständig im Software Testing Leadership Handbook beschrieben. Das Buch ist nach Fragen aufgebaut, nicht nach Kapiteln, die man von vorn bis hinten liest. Das passt dazu, wie vielbeschäftigte Menschen tatsächlich suchen: Die genaue Antwort kennst du selten, deine Frage aber schon. Wie mache ich das Testen vielfältiger? Wie gehe ich mit den Fachbegriffen des Testens um? Wie finde ich Tester?
Das Buch hat fast 300 Seiten und geht weit über die acht Zeichen hinaus, die nur den Einstieg bilden. Geschrieben ist es für Leser auf CTO- oder CXO-Ebene, also für Menschen, die eine Zusammenfassung lesen und dann bei ihrer konkreten Sorge in die Tiefe gehen. Praktische Anleitungen zum Testen enthält es bewusst nicht. Beim Schreiben flogen Kapitel, die zu sehr ins technische Detail auf Tester-Ebene abdrifteten, raus, ungefähr die Hälfte davon, damit der Fokus auf dem Führungsdenken bleibt. Was übrig blieb, taugt auch für Testmanager, Tester und sogar für IT-Studierende.
Häufig gestellte Fragen
Woran erkennt man, ob es einem Unternehmen an Führung im Testbereich mangelt?
Vergleiche, wie die Geschäftsleitung über Entwicklung und über das Testen spricht. Ein CTO kann in der Regel die Sprachen nennen, die die Entwickler verwenden, und sagen, wer für die Architektur verantwortlich ist, beschreibt das Testen aber vage als das Ausführen einiger Automatisierungen und das Durchführen einiger Überprüfungen. Die Teams testen vielleicht trotzdem gut auf eigene Faust. Was fehlt, befindet sich eine Etage höher: jemand, der die Voraussetzungen und die Kultur für gutes Testen schafft.
Muss ein CEO oder CTO wissen, wie man testet, um das Testen zu leiten?
Nein. Niemand erwartet von einer Führungskraft, dass sie Tests manuell durchführt oder jedes Testverfahren beherrscht. Sie brauchen genug Verständnis, um aktiv in den Zusammenhang zwischen der Führung eines Unternehmens, der Beauftragung von Software und der Entwicklung und dem Testen dieser Software eingebunden zu bleiben. Ihr eigentlicher Beitrag besteht darin, immer wieder über Tests und Qualität zu sprechen, damit dies niemals zur alleinigen Verantwortung eines einzelnen Teams wird.
Zu welchem Zeitpunkt in einem Softwareprojekt sollte das Testen berücksichtigt werden?
Lange bevor es überhaupt Code gibt. Das Testen gehört in die Budgetgespräche, in die Entscheidung darüber, welcher Anbieter oder Lieferant die Software entwickelt, und in den Plan für den Betrieb des Produkts in der Produktion. Jeder dieser Momente wirft eine Frage auf: Wie stelle ich sicher, dass das funktioniert? Wie überprüfe ich es in der Produktion? Wie bestätige ich, dass es das tut, was es soll?
Gibt es einen einzigen besten Testansatz, der in jedem Projekt funktioniert?
Nein. Der richtige Ansatz hängt vom Unternehmen, dem Fachgebiet, der Technologie, dem Team, dem Budget und davon ab, ob es eilig ist. Kontextgesteuertes Testen bedeutet, die Methoden an diese Bedingungen anzupassen, anstatt ein festes Schema anzuwenden. Es gibt keine universell beste Technik, die nur darauf wartet, ausgewählt zu werden, und was in einem Umfeld funktioniert, kann in einem anderen falsch sein.
Kann Testautomatisierung menschliche Tester ersetzen?
Nein. Automatisierung, Delivery-Pipelines und CI/CD entwickeln sich ständig weiter und sind nützlich, aber sie liefern keine explorative Arbeit, keine Kreativität und keine neuen Ideen. Das leisten menschliche Tester. Jede Seite deckt das ab, was die andere nicht kann; daher geht es darum, beides in deinen eigenen Kontext einzubinden, anstatt das eine anstelle des anderen zu wählen.
Was verlangt der Aufbau einer Qualitätskultur eigentlich von Führungskräften?
Vor allem Wiederholung von ganz oben. Führungskräfte machen gutes Testen zu einer Selbstverständlichkeit und sorgen dafür, dass es normal ist, über Probleme und Fehler zu sprechen, daraus zu lernen und niemanden dafür verantwortlich zu machen. Je höher du in der Hierarchie stehst, desto wichtiger ist es, dass du Qualität immer wieder in den Vordergrund stellst. Die bequeme Alternative, zu sagen: „Wir haben ein paar Tester, die machen eben ihr Ding“, ist eine Gewohnheit, die es wert ist, abgelegt zu werden.
Brauchen selbstorganisierte Teams immer noch einen eigenen Leiter für das Testen?
In großem Maßstab, ja. Autonome Teams sind wertvoll, aber wenn jedes Team das Testen auf seine eigene Art handhabt, reicht das in einer großen Organisation nicht aus, und der CTO ist oft ein ehemaliger Architekt, Entwickler oder Geschäftsmann. Bei dieser Rolle geht es nicht um Kontrolle: Sie legt allgemeine Richtlinien als Mindeststandards fest, überlässt es den Teams, das Passende zu finden, und unterstützt Communities, in denen Menschen Ideen austauschen.
Warum wählt man nicht einfach das beste Testtool und den besten Ansatz aus?
Qualität entsteht nicht aus einer einzigen Perspektive. Stell dir eine Taschenlampe in einer Höhle vor: Wenn du sie auf eine Stelle richtest, siehst du diese Stelle, nicht die Höhle. Man braucht mehrere Perspektiven, um das Ganze zu sehen. Verschiedene Techniken, Menschen, Ansätze, Anbieter und Umgebungen unterstützen sich gegenseitig. Deshalb steht Vielfalt in den Prinzipien des Modells direkt hinter „Ermöglichen“.
