ACT2LEAD ist ein Führungsmodell für das Testen von Software, das acht Prinzipien als Akronym bündelt: Alles einbeziehen, Kontext verstehen, Transparenz schaffen, zwei Ebenen (Automatisierung und Mensch) verbinden, Lernen, Testkultur fördern, an Risiken anpassen und Diversität 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.
