ACT2LEAD ist ein Führungsmodell für das Testen von Software, das acht Prinzipien als Akronym bündelt: Add (Testen überall mitdenken), Context (Kontext verstehen), Transparency (Transparenz schaffen), Two (Automatisierung und Mensch verbinden), Learning (Lernen), Enable (Qualitätskultur schaffen), Adapt to risk (an Risiken anpassen) und Diversity (Vielfalt sicherstellen). Es richtet sich an alle Unternehmensebenen, nicht nur an Tester.
Das Wichtigste in Kürze
- Testkultur entsteht nicht von selbst: Ohne jemanden, der Testen aktiv auf Führungsebene einbringt und immer wieder benennt, bleibt es auf Team-Ebene stecken.
- Das ACT2LEAD-Modell fasst acht Prinzipien zusammen, darunter Kontext, Transparenz, Lernen, Risikoanpassung und Vielfalt, die zusammen eine organisationsweite Testpraxis ermöglichen.
- Automatisierung und menschliches Testen schließen sich nicht aus: Exploratives Testen und Kreativität lassen sich nicht automatisieren und bleiben unverzichtbar.
- Wer verstehen will, wie eine Software wirklich funktioniert, sollte die Tester fragen, denn sie haben als Einzige den vollständigen Überblick über Verhalten, Risiken und tatsächliche Funktionsweise.
- Führungskräfte auf CXO-Ebene müssen nicht selbst testen, aber sie müssen genug über Testen wissen, um zwischen Geschäftsanforderungen und Softwareentwicklung aktiv vermitteln zu können.
Führung fehlt im Testen, nicht das Testen selbst
Das größte Defizit beim Software-Testing liegt nicht auf Team-Ebene, sondern darüber. Die Teams testen meist ordentlich, sie organisieren sich selbst, sie liefern. Was fehlt, ist die Führung, die Testen und Qualität im ganzen Unternehmen verankert.
Kari Kakkonen beschreibt ein wiederkehrendes Muster: Je höher man in einem Unternehmen steigt, desto weniger Verständnis für Testen trifft man an. Auf oberer Ebene weiß man, dass getestet werden muss. Man verlangt es sogar. Aber was Testen bedeutet und wie gute Qualität entsteht, bleibt unklar.
Daraus folgt eine einfache These: Je besser jemand Testen versteht, desto besser kann er es führen. Und desto eher kann er von seinen Leuten gute Qualität erwarten und ihnen den Raum geben, sie zu liefern.
Warum autonome Teams allein nicht reichen
In einem großen Unternehmen genügt es nicht, wenn jedes Team sein eigenes Testen macht. Autonome Teams sind gut, und Kari ist erklärter Verfechter davon. Das Problem entsteht, wenn jedes Team unterschiedlich vorgeht und niemand den Überblick über die gesamte Software behält.
Deshalb braucht es jemanden, der für Testen über Teamgrenzen hinweg verantwortlich ist. Das kann ein Head of Testing sein. Diese Rolle zwingt allen Teams keine identischen Regeln auf, sondern gibt das Nötigste vor: ein paar allgemeine Testrichtlinien, an denen sich alle orientieren.
Wie die konkrete Umsetzung aussieht, klärt jedes Team für sich. Ein Mittel dafür sind Test-Communities, in denen Leute ihre Ideen mit anderen teilen, die sich für Testen interessieren. Gemeint ist Testen als Tätigkeit, nicht der Tester als Person. Testen kann nahezu jeder lernen.
ACT2LEAD: eine Heuristik für Testführung
ACT2LEAD ist ein Akronym, das die wichtigsten Elemente guter Testführung in acht Buchstaben fasst. Der Sinn dahinter ist Merkbarkeit: Eine kurze Formel lässt sich leichter behalten und leichter umsetzen als ein dicker Leitfaden. Jeder Buchstabe steht für ein Prinzip.
Die folgende Übersicht ordnet die acht Buchstaben:
| Buchstabe | Prinzip | Kern |
|---|---|---|
| A | Add | Testen überall mitdenken, nicht erst beim Code |
| C | Context | Testen hängt vom Kontext ab |
| T | Transparency | Ergebnisse sichtbar machen statt verstecken |
| 2 | Two (Automation + Human) | Automatisierung und Mensch zusammen |
| L | Learning | Testen, um zu lernen, und lernen, um zu testen |
| E | Enable | Kultur für gute Qualität schaffen |
| A | Adapt to risk | Tests am Risiko ausrichten |
| D | Diversity | Vielfalt in Methoden, Menschen, Ansätzen |
Add: Testen beginnt vor dem Code
Testen findet nicht erst statt, wenn Code vorliegt. Es beginnt beim Budget für eine Software und bei der Frage, welchen Anbieter du mit der Entwicklung beauftragst. Auch in diese Entscheidung gehört der Gedanke ans Testen.
Genauso reicht Testen über die Auslieferung hinaus. Wie betreibe ich meine Software in Produktion? Wie stelle ich sicher, dass sie tatsächlich funktioniert, und wie überprüfe ich das? Diese Fragen sind Teil des Testens.
Context: Testen ist nie überall gleich
Welche Tests sinnvoll sind, hängt vom Kontext ab. Du musst die Domäne verstehen, die eingesetzte Technologie, das Team, das Budget und den Zeitdruck. Tests werden entsprechend ausgewählt, nicht nach einem festen Schema.
Transparency: nicht verstecken, sichtbar machen
Testarbeit gehört offengelegt. Teile Testergebnisse, teile gefundene Fehler, sprich Qualitätsprobleme an. Wer Qualität sichtbar macht, erhöht die Chance, dass alle mit anpacken.
Sichtbarkeit heißt nicht, jeden mit Details zu überfluten. Kennzahlen und Mängel werden für das jeweilige Publikum aufbereitet, etwa über Dashboards, die ein schnelles Bild der Qualität geben.
Besonders zählt Transparenz, wenn mehrere Anbieter oder Lieferanten beteiligt sind. Dann ist es leicht, Grenzen zu ziehen und einfach darauf zu vertrauen, dass der andere seinen vertraglich zugesicherten Teil testet. Statt blind zu vertrauen, gilt: sichtbar machen, was erwartet wird, was geliefert wird und was tatsächlich passiert.
Two: Automatisierung und Mensch zusammen
Du brauchst beides, Automatisierung und Menschen. Auch wenn die Welt immer mehr automatisiert, von Testautomatisierung bis CI/CD-Pipelines, ersetzt das echte Menschen nicht.
Exploratives Testen, Kreativität und neue Ideen kommen von Menschen. Die Aufgabe der Führung ist, einen Weg zu finden, der zur eigenen Situation passt und beidem seinen Platz gibt.
Learning: testen, um zu lernen
Du kannst nicht im Voraus wissen, was eine Software wirklich braucht. Du probierst, und dabei lernst du, wie sie funktioniert und wie du deine Tests verbessern kannst.
Aus dieser Doppelbewegung folgt eine der stärksten Eigenschaften des Berufs: Tester verstehen das Gesamtbild. Sie durchdenken Software aus vielen Blickwinkeln, im Hinblick auf Risiken, auf das Soll und auf das tatsächliche Verhalten.
Wenn du jemanden fragen musst, wie diese Software funktioniert und worum es bei ihr geht, geh zum Tester. Der Tester hat den Überblick. (Kari Kakkonen)
Enable: Qualitätskultur ist Chefsache
Das wichtigste Prinzip ist E für Enable. Führung schafft die Bedingungen, unter denen gut getestet und gut gelernt werden kann. Dazu gehört, über Probleme zu sprechen und aus Fehlern zu lernen, statt Schuld zuzuweisen, und zwar täglich.
Je höher die Ebene, desto wichtiger wird das wiederholte Bekenntnis: Testen ist wichtig, Qualität zählt. Niemand erwartet, dass ein CEO praktisch testet. Aber er sollte über Testen und Qualität sprechen und sie nicht an ein einzelnes Team delegieren.
Adapt to risk: mehr Tests, wo das Risiko hoch ist
Tests werden am Risiko ausgerichtet. In Bereichen mit hohem Risiko wird mehr getestet. Das ist die einfache Regel hinter dem zweiten A.
Diversity: nicht das eine beste Werkzeug
Testen muss vielfältig sein, in jeder Hinsicht. Verschiedene Testmethoden, verschiedene Ansätze, verschiedene Menschen, mehrere Anbieter, mehrere Umgebungen.
Die häufige Manager-Frage nach der einen besten Option führt in die Irre. Es gibt nicht das eine beste Tool und nicht den einen Ansatz für alles. Verschiedene Blickwinkel ergänzen einander, und erst daraus entsteht gute Qualität.
Ein Bild dafür: Wer mit einer Taschenlampe in einer Höhle steht und sie an eine Stelle richtet, sieht genau diese Stelle. Die Höhle sieht er nicht. Erst mehrere Blickwinkel ergeben das vollständige Bild.
Warum CTOs Testen schlechter erklären können als Code
Ein verbreitetes Symptom zeigt das Defizit deutlich. Fragst du einen CTO, was im Unternehmen getestet wird, kommt oft eine vage Antwort: vermutlich Testautomatisierung, ein paar Reviews. Das ist ein Anfang, reicht aber nicht.
Fragst du dieselbe Person, was die Entwickler oder Architekten tun, werden die Antworten präziser. Sie wissen, dass Code geschrieben wird, dass Versionsverwaltung genutzt wird, dass irgendwo Python steht und anderswo Java. Beim Testen bleibt die Antwort grob.
Das beweist keinen Unwillen, sondern fehlendes Testwissen auf oberer Ebene. Und genau das lässt sich beheben.
Wie ein Handbuch für die CXO-Ebene aufgebaut ist
Das von Kari und seinem Co-Autor Marko Rytkönen verfasste “Software Testing Leadership Handbook” geht deutlich tiefer als die acht Buchstaben. Auf knapp 300 Seiten bündelt es das, was Führungskräfte über Testen wissen müssen.
Der Aufbau folgt Fragen statt Kapiteln. Wer Antworten sucht, weiß oft nicht genau, was er braucht, hat aber eine Frage. Wie mache ich Testen vielfältiger? Wie gehe ich mit Testphasen um? Wie finde ich Tester? So findet eine vielbeschäftigte Führungskraft den Einstieg über ihre konkrete Sorge, liest die Zusammenfassung und vertieft nur, was sie betrifft.
Bewusst weggelassen wurde, wie man testet. Beim Schreiben fiel auf, dass Teile zu technisch wurden und in Richtung Tester abdrifteten. Etwa die Hälfte der Kapitel wurde gestrichen, weil sie nicht zur Denkweise und zum Bedarf der CXO-Ebene passten. Geschrieben für die Führungsetage, funktioniert das Buch am Ende auch für Testmanager, Tester und IT-Studierende, die sich Grundlagen aneignen wollen.
Häufig gestellte Fragen
Wo liegt das größte Defizit beim Software-Testing in Unternehmen?
Nicht auf Team-Ebene, sondern darüber. Die Teams testen meist ordentlich, organisieren sich selbst und liefern. Was fehlt, ist Führung, die Testen und Qualität im ganzen Unternehmen verankert. Kari Kakkonen beschreibt ein wiederkehrendes Muster: Je höher man in der Hierarchie steigt, desto weniger Verständnis fürs Testen trifft man an. Getestet werden soll, aber was Testen bedeutet, bleibt unklar.
Braucht es eine zentrale Rolle für Testen, wenn die Teams autonom arbeiten?
Ja, sobald das Unternehmen groß genug ist. Autonome Teams sind sinnvoll, doch wenn jedes Team anders vorgeht, behält niemand den Überblick über die gesamte Software. Eine Rolle wie Head of Testing zwingt keine identischen Regeln auf, sondern gibt nur wenige allgemeine Testrichtlinien vor. Die konkrete Umsetzung klärt jedes Team selbst, etwa im Austausch über Test-Communities.
Wofür steht das Akronym ACT2LEAD?
ACT2LEAD bündelt acht Prinzipien der Testführung: Add (Testen überall mitdenken), Context (Testen hängt vom Kontext ab), Transparency (Ergebnisse sichtbar machen), Two (Automatisierung und Mensch), Learning (testen, um zu lernen), Enable (Kultur für Qualität schaffen), Adapt to risk (Tests am Risiko ausrichten) und Diversity (Vielfalt in Methoden, Menschen, Ansätzen). Der Sinn der kurzen Formel ist Merkbarkeit: Sie bleibt eher hängen als ein dicker Leitfaden.
Ab wann in einem Projekt sollte Testen mitgedacht werden?
Deutlich vor dem Code. Testen beginnt beim Budget für eine Software und bei der Entscheidung, welchen Anbieter du mit der Entwicklung beauftragst. Auch dort gehört der Gedanke ans Testen hinein. Ebenso endet Testen nicht mit der Auslieferung: Wie die Software in Produktion betrieben wird und wie man dort ihr Funktionieren überprüft, zählt ebenfalls dazu.
Macht Testautomatisierung menschliche Tester überflüssig?
Nein. Automatisierung und Menschen werden beide gebraucht, auch wenn von Testautomatisierung bis zu CI/CD-Pipelines immer mehr automatisiert läuft. Exploratives Testen, Kreativität und neue Ideen kommen von Menschen und lassen sich nicht automatisieren. Die Führungsaufgabe besteht darin, für die eigene Situation eine Aufteilung zu finden, die beidem seinen Platz gibt.
Wen sollte man fragen, wenn man verstehen will, wie eine Software wirklich funktioniert?
Den Tester. Er hat als Einziger den vollständigen Überblick, weil er die Software aus vielen Blickwinkeln durchdenkt: im Hinblick auf Risiken, auf das Soll und auf das tatsächliche Verhalten. Dieser Überblick entsteht aus der Doppelbewegung des Testens: Man testet, um zu lernen, wie die Software funktioniert, und lernt dabei, die Tests zu verbessern.
Müssen Führungskräfte auf CXO-Ebene selbst testen können?
Nein. Niemand erwartet, dass ein CEO praktisch testet. Er sollte aber genug über Testen wissen, um zwischen Geschäftsanforderungen und Softwareentwicklung aktiv zu vermitteln, und er sollte Testen und Qualität regelmäßig ansprechen, statt sie an ein einzelnes Team zu delegieren. Je höher die Ebene, desto mehr zählt dieses wiederholte Bekenntnis.
Gibt es das eine beste Testwerkzeug oder den einen richtigen Testansatz?
Nein, und die häufige Manager-Frage nach der einen besten Option führt in die Irre. Nötig sind verschiedene Testmethoden, verschiedene Ansätze, verschiedene Menschen, mehrere Anbieter und mehrere Umgebungen. Das Bild dazu: Wer in einer Höhle die Taschenlampe auf eine Stelle richtet, sieht genau diese Stelle, nicht die Höhle. Erst mehrere Blickwinkel ergeben das vollständige Bild.
