Software Testleiter

ACT2LEAD ist ein Führungsmodell für das Testen von Software, das auf acht Prinzipien beruht: Testen zu allem hinzufügen, kontextabhängige Entscheidungen, Transparenz über Qualität, zweiseitiges Testen (Automatisierung und menschliches Testen), Lernen durch Testen, eine Qualitätskultur ermöglichen, sich an Risiken anpassen und Vielfalt der Ansätze. Das Modell besagt, dass das Testen auf Organisationsebene aktiv gesteuert werden muss und nicht nur einzelnen Teams überlassen werden darf.

Das Wichtigste in Kürze

• In den meisten Unternehmen fehlt es an Führungskräften, die das Testen leiten: Das Management weiß, dass Testen stattfinden muss, kann aber nicht erklären, was es eigentlich beinhaltet, im Gegensatz zu ihrem Verständnis von Entwicklung oder Architektur.
• Das ACT2LEAD-Modell gliedert die Führung im Testen in acht Bereiche: Testen zu allem hinzufügen, Kontext, Transparenz, Automatisierung und Menschen, Lernen, Qualitätskultur ermöglichen, Risiken anpassen und Vielfalt.
• Das Ermöglichen einer Qualitätskultur (das E in ACT2LEAD) erfordert, dass die Führungskräfte ständig über Testen und Qualität sprechen und die Verantwortung nicht ausschließlich an die Entwicklungsteams delegieren.
• Große Organisationen brauchen einen engagierten Testleiter, z. B. einen Head of Testing, der für alle Teams Mindeststandards festlegt, denn autonome Teams, die ihre eigenen Tests auf unterschiedliche Art und Weise durchführen, sind in dieser Größenordnung nicht ausreichend.
• Gutes Testen erfordert eine Vielfalt an Techniken, Menschen, Ansätzen und Umgebungen, denn kein einziges Werkzeug oder Verfahren deckt alle Aspekte ab, die ein komplexes Softwareprodukt erfordert.

Warum es beim Testen von Software an Führung mangelt

Die meisten Unternehmen verwalten das Testen auf Teamebene, führen es aber selten an. Die Teams planen ihre Arbeit, führen ihre Tests durch und organisieren sich selbst, und auf der Basisebene funktioniert 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 in seiner Karriere immer wieder das gleiche Muster beobachtet. Wenn du in einer Organisation hoch genug aufsteigst, findest du Leute, die zwar wissen, dass Testen notwendig ist, aber nicht sagen können, was es eigentlich bedeutet. Sie schreiben vielleicht “Testen ist notwendig” in eine Anforderung und lassen sie dann ungeprüft stehen.

Die Kluft wird deutlich, wenn du Fragen vergleichst. Frag einen CTO, was die Entwickler tun, und die Antwort ist präzise: Sie schreiben Code in Python hier, C dort, Java irgendwo anders, sie kümmern sich um die Architektur. Frag dieselbe Person, was die Tester tun, und die Antwort dünnt sich aus auf “Ich nehme an, sie führen eine Testautomatisierung durch und machen ein paar Prüfungen.” Diese Unbestimmtheit ist das Symptom für fehlendes Wissen über das Testen.

Je mehr du das Testen verstehst, desto besser kannst du es leiten

Um beim Testen zu führen, muss man es verstehen. Du musst nicht jede Technik im Detail kennen, aber du brauchst genug, um in der Beziehung zwischen dem Führen eines Unternehmens, der Beauftragung von Software und dem Erstellen und Testen dieser Software aktiv zu sein.

Das ist das Kernargument hinter dem ACT to LEAD-Modell, das Kari zusammen mit seinem Co-Autor Marko Rytkönen entwickelt hat. Der Name ist eine Heuristik, acht Buchstaben, die jeweils für ein Prinzip stehen. Es ist so aufgebaut, dass man es sich merken und umsetzen kann, statt es wegzulegen. Es geht darum, das Testen im ganzen Unternehmen auf die Tagesordnung zu setzen, nicht nur in der täglichen Routine der Tester.

Von einem leitenden Angestellten wird nicht erwartet, dass er Tests von Hand ausführt. Es wird von ihnen erwartet, dass sie immer wieder über Testen und Qualität sprechen und es nicht zulassen, dass das Thema in der privaten Verantwortung eines Teams untergeht.

Was das ACT to LEAD-Modell umfasst

Mit ACT to LEAD wird der Gedanke des Testens auf die Bereiche Budgetierung, Lieferantenauswahl, Produktion und Teamkultur ausgeweitet, anstatt ihn auf den Moment zu beschränken, in dem der Code eintrifft. Jeder Buchstabe steht für ein Arbeitsprinzip.

Testen Sie alles, nicht nur den Code

Testen fängt lange vor der Erstellung des Codes an. Es gehört in die Budgetdiskussion, in die Entscheidung darüber, welcher Lieferant oder Anbieter deine Software erstellt, und in die Planung, wie du das Produkt betreiben willst, sobald es in Produktion geht.

In jedem dieser Momente stellt sich eine Frage zum Testen. Wie stelle ich sicher, dass es funktioniert? Wie kann ich es in der Produktion testen? Wie bestätige ich, dass es tatsächlich das tut, was es tun soll? Wenn man das Testen als eine Phase betrachtet, die mit der Veröffentlichung des Codes beginnt, geht man an den meisten Punkten vorbei, an denen man denken muss.

Der Kontext entscheidet darüber, wie gutes Testen aussieht

Testen ist nicht überall das Gleiche. Die richtige Herangehensweise hängt vom Geschäft, der Domäne, der Technologie, dem Team, dem Budget und davon ab, ob du in Eile bist.

Kontextorientiertes Testen bedeutet, dass du deine Methoden an diese Bedingungen anpasst, anstatt ein festes Regelwerk anzuwenden. Es gibt keine universelle beste Methode, die nur darauf wartet, ausgewählt zu werden. Was in einer Umgebung funktioniert, kann in einer anderen falsch sein.

Warum Transparenz das Vertrauen zwischen Anbietern übertrifft

Transparenz bedeutet, dass du das Testen sichtbar machst und die Informationen weitergibst, anstatt stillschweigend darauf zu vertrauen, dass die anderen Beteiligten ihren Teil tun. Wenn du Fehlerzustände oder Qualitätsprobleme feststellst, gibt das allen die Möglichkeit, sich einzubringen.

Das Risiko steigt, wenn mehrere Beteiligte, Anbieter oder Zulieferer zusammenarbeiten. Es entstehen leicht Grenzen. Jede Partei leistet ihren Beitrag, ein Vertrag legt fest, wer was testet, und der Rest verschwindet hinter “wir vertrauen ihnen einfach” Transparenz ersetzt blindes Vertrauen durch Sichtbarkeit: was du anforderst, was du bekommst und was tatsächlich passiert.

Sichtbarkeit ist nicht dasselbe wie die Überflutung mit Daten. Jede Metrik und jeder Fehlerzustand führt zu einer Informationsflut und verfehlt den Zweck. Die Arbeit besteht darin, die Informationen zusammenzufassen, sie an die Zielgruppe anzupassen und Dashboards zu erstellen, die Qualität leicht lesbar machen, ohne etwas zu verbergen.

Du brauchst immer Automatisierung und Menschen

Testen braucht beides: Automatisierung und Menschen, nie das eine anstelle des anderen. Der Trend zur Automatisierung ist ungebrochen: mehr Testautomatisierung, mehr Lieferautomatisierung, mehr CI/CD-Pipelines. Das ist nützlich, aber es reicht nicht aus.

Menschliche Tester bringen Erkundungsarbeit, Kreativität und neue Ideen ein, die die Automatisierung nicht hervorbringt. Deine Aufgabe ist es, beides in deinen eigenen Kontext einzubinden, denn das eine deckt ab, was das andere nicht kann.

Tester lernen die Software tiefer kennen als jeder andere

Wenn du eine Person brauchst, die dir erklärt, wie eine Software funktioniert, frag den Tester. Tester sind eher breit als eng gefächert. Sie lernen das gesamte Produkt kennen, wo jedes Teil hingehört, wie es sich verhalten sollte und wie es sich tatsächlich verhält.

Dieses breite Wissen kommt von der Arbeit selbst. Ein Tester braucht ein umfassendes Bild, um seine Arbeit zu machen. Er muss die Software aus vielen Blickwinkeln und gegen viele Risiken prüfen. Das Lernen geht in beide Richtungen: Du testest, um das System kennenzulernen, und du lernst dabei, wie du es besser testen kannst.

Die Schaffung einer Qualitätskultur ist die eigentliche Aufgabe der Führungskraft

Das wichtigste Prinzip ist die Ermöglichung: die Schaffung von Bedingungen, unter denen gutes Testen möglich ist. Mache gutes Testen zu einer Erwartung. Mach es zur Normalität, über Probleme und Fehlerwirkungen zu sprechen, aus ihnen zu lernen und sie nicht den anderen vorzuwerfen.

Dabei geht es vor allem um Wiederholungen von oben. Je höher du in einem Unternehmen sitzt, desto wichtiger ist es, dass du das Testen und die Qualität immer wieder als etwas Wichtiges benennst. Ein CEO wird nicht von Hand testen, aber er kann dafür sorgen, dass das Thema Qualität im Gespräch bleibt, anstatt es als einsame Aufgabe des Teams weiterzugeben.

Für viele Unternehmen ist das ein echter Kulturwandel. Der einfache Weg ist, zu sagen: “Wir haben ein paar Tester, die machen, was sie machen” und weiterzumachen. Mit dieser Gewohnheit zu brechen, ist die Veränderung, die sich lohnt.

Anpassungsfähigkeit an Risiken und Vielfalt beim Testen

Richte dein Testen nach dem Risiko aus. Bereiche mit hohem Risiko erhalten mehr Aufmerksamkeit und werden intensiver getestet. Das Prinzip ist einfach, und wenn du es anwendest, bleibt der Aufwand dort, wo er am meisten Nutzen bringt.

Diversität ist gleich nach der Befähigung wichtig. Nutze mehrere Techniken, mehrere Personen, mehrere Ansätze, mehrere Lieferanten, mehrere Umgebungen. Unterschiedliche Blickwinkel unterstützen sich gegenseitig und sorgen gemeinsam für bessere Qualität.

Wenn du eine Person fragst, wie diese Software funktioniert, worum es bei dieser Software geht, solltest du dich an den Tester wenden, denn er hat das Gesamtbild.

Kari Kakkonen

Der Instinkt eines Managers besteht oft darin, nach der besten Lösung zu fragen: das beste Werkzeug, die beste Vorgehensweise, Automatisierung für alles. Qualität kommt aber nicht aus einem einzigen Blickwinkel. Stell dir eine Taschenlampe in einer Höhle vor. Richte sie auf einen Punkt und du siehst diesen Punkt, nicht die Höhle. Du brauchst mehrere Perspektiven, um das Ganze zu sehen.

Wer hat in einem großen Unternehmen die Leitung des Testens inne?

Große Unternehmen brauchen einen Verantwortlichen für das Testen, z. B. einen Leiter des Testens. Zu oft ist der CTO ein ehemaliger Architekt, Entwickler oder Geschäftsmann, was auch in Ordnung ist, aber jemand muss dafür sorgen, dass das Testen im gesamten Produkt stattfindet.

Autonome, selbstorganisierende Teams sind wertvoll, und Kari unterstützt sie. Doch wenn jedes Team seine eigenen Tests auf seine eigene Weise durchführt, reicht das im großen Maßstab nicht aus. Bei der Rolle des Leiters des Testens geht es nicht darum, im Sinne einer Kontrolle “das Sagen” zu haben. Es geht darum, sicherzustellen, dass das Testen überall dort stattfindet, wo die Software entwickelt wird.

Die praktischen Werkzeuge sind einfach. Lege allgemeine Richtlinien für das Testen fest, die ein Minimum vorgeben, anstatt jedem Team identische Regeln zu diktieren: Mach mindestens so viel und finde dann die Wege, die zu deinem Team und deinem Kontext passen. Unterstütze das mit Test-Gemeinschaften, in denen Menschen Ideen austauschen. Es heißt Testen, nicht Tester, denn Testen ist etwas, an dem sich jeder beteiligen kann.

Ein Führungshandbuch, das aus Fragen besteht

ACT to LEAD ist vollständig im Software Testing Leadership Handbook enthalten, das aus Fragen besteht und nicht aus Kapiteln, die man von vorne nach hinten liest. Das Format entspricht der Art und Weise, wie vielbeschäftigte Menschen tatsächlich suchen: Du weißt selten die genaue Antwort, die du brauchst, aber du kennst deine Frage. Wie kann ich das Testen vielfältiger gestalten? Wie gehe ich mit den Begriffen des Testens um? Wie rekrutiere ich Tester?

Das Buch umfasst fast 300 Seiten und geht weit über die acht Buchstaben hinaus, die als Einstieg dienen. Es wurde für Leser auf CTO- oder CXO-Ebene geschrieben, also für jemanden, der eine Zusammenfassung lesen und dann in die Tiefe gehen kann, wenn er eine Sorge hat. Es enthält bewusst keine praktischen Anweisungen zum Testen. Während des Schreibens wurden Kapitel, die zu sehr in technische Details auf Tester-Ebene abdrifteten, etwa um die Hälfte gekürzt, um den Fokus auf das Führungsdenken zu legen. Die verbleibenden Kapitel sind für Testmanager, Tester und sogar für IT-Studenten geeignet.