Testen als Versicherung: Mit Zahlen Manager überzeugen

Testökonomie heißt, Entscheidungen über Softwarequalität in finanziellen Größen zu formulieren, damit Tester, Entwickler und Manager dieselbe Sprache sprechen. Testen gilt dabei als Versicherung gegen teure Fehlerwirkungen. Verschwendung wie Nacharbeit und Kundenabwanderung wird beziffert, und Qualitätsargumente werden in Zahlen übersetzt, mit denen Manager ohnehin arbeiten: verlorene Arbeitsstunden, entgangene Aufträge und Kunden, die gehen, weil Fehler liegen bleiben.

Das Wichtigste in Kürze

• Wer Testentscheidungen in finanziellen Größen formuliert, hat eine klare Rückfallposition: Setzt sich ein Manager über eine Risikowarnung hinweg, kann der Tester eine schriftliche Freigabe verlangen, und die schützt seinen Job.
• Zuerst sichtbare, wiederkehrende Verschwendung abzubauen, etwa Features, die vom Test in die Entwicklung zurückgehen, weil sie nicht testbar sind, schafft die Glaubwürdigkeit für größere Investitionen in Qualität.
• Tester sind näher am echten Nutzerverhalten als Produktmanager, weil sie in Regressionstests und explorativen Tests die ganze User Journey durchlaufen, von der Registrierung bis zur Kündigung.
• Die Zeit, die der Kundensupport damit verbringt, Nutzerbeschwerden bestehenden Fehlerberichten zuzuordnen, ist ein direkter, messbarer Kostenfaktor. Damit lässt sich ein Business Case für bessere QS begründen, ganz ohne aufwendige Finanzmodelle.

Warum Tester und Manager bei Release-Entscheidungen aneinander vorbeireden

Wer Manager von mehr Qualität überzeugen will, kommt mit Testen als Versicherung weiter als mit Bauchgefühl. Denn Tester und Manager sprechen oft dieselbe Sprache und verstehen sich trotzdem nicht. Über technische Details können sie reden. Der Streit beginnt, sobald eine Release-Entscheidung ansteht: mehr testen oder weniger, jetzt ausliefern oder verschieben.

Vitaly Sharovatov ist seit mehr als zwanzig Jahren in der IT, als Freelancer und als Angestellter, und hat diese Kluft in einer Firma nach der anderen gesehen. Die Diskussionen über Releases waren subjektiv und meinungsgetrieben. Ein Tester mit hohem Ansehen im Unternehmen konnte einfach sagen: “Das gebe ich nicht frei.” Genauso einfach konnte ein Vorgesetzter das Release durchdrücken.

Die eigentliche Ursache ist ein fehlender gemeinsamer Rahmen. Manager werden an wirtschaftlichen Größen gemessen: KPIs, OKRs, Umsatz. Die Hypothese eines Produktmanagers lautet, dass ein Feature, das jetzt live geht, Nutzer, Wert und Geld bringt. Sagt der Tester Nein, wird er in den Augen des Managers zum Gatekeeper.

Vitaly hat erlebt, wie Tester wegen solcher Missverständnisse gestritten haben, gekündigt haben und gefeuert wurden. Erzwungene Releases gibt es auch in die andere Richtung, wenn Manager Risiken ignorieren, auf die Tester und Entwickler hingewiesen haben. Sein Fazit: Tester sollten zumindest die Sprache lernen, die Manager ohnehin sprechen.

Testen als Versicherung, nicht als Kostenfaktor

Gute QS erzeugt ein seltsames Paradox. Wird gut getestet, gibt es in Produktion keine oder kaum Vorfälle. Du bezahlst mit Aufwand und Zeit für Dinge, die nie passieren.

Genau so funktioniert eine Versicherung, und das versteht jeder Manager. Bei der Krankenversicherung zahlst du jeden Monat für einen Fall, der hoffentlich nie eintritt. Brichst du dir in den USA ohne Versicherung ein Bein, zahlst du die ganze Rechnung selbst.

Investitionen folgen derselben Logik: Du zahlst jetzt für ein besseres Ergebnis später. Tester können nicht garantieren, dass es keine Bugs und keine Vorfälle gibt. Sie können aber ein Modell aufbauen, das Schaden, Auswirkung oder Wahrscheinlichkeit senkt, dass Nutzern etwas Schlimmes passiert.

Mit diesem Blick ändert sich das Gespräch. Statt “Vertrau mir, wir müssen mehr testen” beschreibst du das Risiko und die wahrscheinlichen Kosten eines schlechten Releases und lässt den Manager entscheiden. Hältst du das schriftlich fest, muss er die Entscheidung abzeichnen. Das schützt auch dich als Tester. Ein Risiko, das der Vorgesetzte schriftlich akzeptiert hat, kann er dir später nicht anlasten, und niemand kann dich dafür feuern.

Wo die Zahlen zu den Kosten schlechter Qualität schon liegen

Die wirtschaftlichen Argumente für Qualität liegen in anderen Abteilungen und müssen nur eingesammelt werden. Tester müssen keine Zahlen erfinden. Sie müssen die richtigen Leute nach Daten fragen, die es schon gibt.

Regulierung ist der sauberste Einstieg, gerade in Europa. Das erste Risiko ist schnell benannt: Was passiert, wenn eine Behörde das Unternehmen dichtmacht? Meist versiegt dann der Geldfluss, und die Firma steht still. Dieses Risiko begreifen Manager sofort, denn fehlende Compliance kann das Aus bedeuten.

Das Marketing liefert die nächste Ebene. Abwanderung, Kosten für die Kundengewinnung und die Gründe, warum Kunden gehen, lassen sich alle messen. Hat das Unternehmen im letzten Jahr eine Million Dollar verloren, weil Kunden das Produkt nicht mehr nutzen, dann hätte man etwas besser machen können. Manchmal ist das ein Feature. Oft sind es UX, Bugs oder Support-Tickets, die monatelang unbeantwortet blieben.

Der Vertrieb kann verlorene Aufträge beziffern. Gewinnt das Team 30 Prozent seiner Deals, frag, was es davon abhält, 50 Prozent zu gewinnen. Ein Teil dieser 20 Prozentpunkte kann an der Qualität liegen. Customer Success kann dir sagen, wie viel Zeit das Team mit Anfragen verbringt, die sich als Fehlerberichte entpuppen. Das sind direkte Kosten in Stunden.

Den letzten Baustein liefert dein eigenes Tracking-System. Zieh die Jira-Statistik heran und schau, wie oft Features vom Test zurück in die Entwicklung wandern. Geht von hundert Features die Hälfte zurück, kannst du die verlorene Zeit und die Kosten der Nacharbeit ausrechnen. Produktmanager interessiert das, weil sie auf die Time to Market schauen: Wie schnell wird aus einer Idee ein Feature, das Leute nutzen können?

Tester kennen die Nutzer besser als fast alle anderen

Tester bringen eine analytische Gewohnheit mit, die zu dieser Arbeit passt. Sie bekommen ein Prüfobjekt, ein Feature, einen Pull Request, und ihr Job ist es, es auseinanderzunehmen. Nach genug Zeit mit einem Produkt verstehen sie die Nutzer oft besser als die Produktmanager.

Produktmanager rutschen leicht in eine Version des Produkts, in der jedes Feature geliebt und gebraucht wird. Tester sehen jeden Tag die Fehlerberichte. Sie lesen direktes Feedback echter Nutzer, genau wie Customer Success.

Regressionstests und explorative Tests zwingen Tester in die Rolle der Nutzer. Sie gehen den ganzen Weg: abonnieren, kaufen, nutzen, kündigen. Damit sind sie gute Kandidaten für den Überblick darüber, was mit dem Produkt tatsächlich passiert.

Tester, die nur Testkonzepte abarbeiten und Testfälle abhaken, brennen eher aus. Immer wieder durch dieselben Prüfungen zu klicken, ohne das große Ganze zu sehen, macht den Job zur seelenlosen Routine. Menschen wollen stolz auf ihre Arbeit sein, und Stolz braucht eine Verbindung zum Ergebnis.

Fang mit der Verschwendung an, die du schon siehst

Ist dein Kalender voll und hört dir niemand zu, starte nicht mit der Idealversion. Marketing, Vertrieb und Management in einen Raum holen, ihre Befürchtungen beziffern und klären, wie stark Testen diese Risiken senkt: Das klappt in manchen Firmen. In vielen schickt dich der Manager einfach zurück ans Testen.

Also geh in kleinen Schritten vor. Untersuche zuerst deine eigene Arbeit auf wiederkehrenden, verschwendeten Aufwand. Das zahlt sich fast immer aus.

Liefert dir ein Entwickler immer wieder Features, die nicht testbar sind oder nicht funktionieren, setz dich mit ihm zusammen. Frag ihn, wie du ihm helfen kannst, sie gleich richtig zu bauen. Entwickler mögen es nicht, wenn Features zurückkommen, also liegt es in eurem gemeinsamen Interesse, euch abzustimmen. Machst du das mit zwei oder drei Entwicklern, werden die Schleifen aus Test und Nacharbeit immer kürzer.

Dann sammle die Zahlen. Für diesen ersten Schritt brauchst du weder Time to Market noch Cost of Delay. Einfache Arbeitsstunden reichen. Zeig deinem QA-Lead, wie viele Stunden du und deine Kollegen gespart habt, belege, dass die Zahlen stimmen, und bitte darum, das Ganze auszuweiten.

“Fang mit den direkten Kosten an, die zu hundert Prozent Verschwendung sind, von denen du weißt und spürst, dass sie Verschwendung sind.”

(Vitaly Sharovatov)

Erst Glaubwürdigkeit aufbauen, dann riskante Änderungen vorschlagen

Die Reihenfolge zählt. Wer offensichtliche Verschwendung abbaut, erarbeitet sich das Standing, bevor er einem Manager etwas vorschlägt, das für ihn riskant aussieht.

Gehst du ins Büro eines Managers und schlägst vor, Einzelarbeit durch Mob Programming zu ersetzen, ist die Antwort absehbar: “Ich zahle doch nicht siebenmal für ein Feature.” Argumente mit Cost of Delay oder Time to Market ziehen dann nicht, weil der Manager eine Bedrohung für den Prozess sieht, den er kennt und dem er vertraut.

Die Reihenfolge, die funktioniert:

Wenn du bei den riskanteren Vorschlägen ankommst, hast du schon gezeigt, dass du Geld sparen kannst. Erst dann kannst du glaubwürdig fordern, Geld in Qualität zu investieren.

Gemeinsamer Nutzen wirkt besser als Autorität

Veränderung per Autorität durchzusetzen, bringt selten etwas, denn Menschen hängen an der Arbeit, in die sie investiert haben. Ein Entwickler, der zwei Monate an einem Feature gebaut hat, freut sich nicht, wenn ein Tester es mit zwanzig Fehlern in einer Aufzählung zurückschickt.

Dieser Sunk-Cost-Reflex ist real, und erfahrene Entwickler wissen das. Die Chance, dass ein Feature nach zwei Monaten Arbeit den Test im ersten Anlauf besteht, ist praktisch null. Deshalb geben erfahrene Entwickler ihre Arbeit viel häufiger und in kleineren Stücken in den Test.

Das Feature zurückzugeben, funktioniert. Besser ist es, sich danach mit dem Entwickler hinzusetzen und eine Lösung zu finden, mit der beide gewinnen. Sind beide Seiten zufrieden, gewinnen deine Initiativen Verbündete, die dich vor der Geschäftsführung unterstützen.

Dasselbe Prinzip gilt nach oben. Manager berichten ihren Vorgesetzten Ergebnisse in Zahlen. Hilfst du einem Manager, bessere Zahlen zu melden, wirst du für ihn wertvoller. Er wird sagen, dass er das Projekt gerettet hat und du geholfen hast. Das ist in Ordnung, denn er weiß, dass du geholfen hast.

Wirtschaftlich denken heißt nicht, alles in eine Tabelle zu pressen

Ein häufiger Einwand: Ökonomisches Denken reduziere alles auf Zahlen. Das stimmt nicht. Qualitative Urteile bleiben im Spiel, die Zahlen geben ihnen Gewicht.

Jedes Unternehmen hat seine eigene Lage. Du kannst einen Ansatz nicht übernehmen, nur weil Amazon ihn nutzt. Ein erfahrener Entwickler stellt einen Umstieg von Angular auf React ja auch mit der Frage infrage, wo die wirtschaftliche Begründung liegt. Im Test gibt es denselben Reflex, ein Framework gegen ein anderes zu tauschen, und er verdient dieselbe Frage.

Wirtschaftlich denken heißt auch, an Menschen denken. Kennt das Team das neue Framework, oder braucht es Einarbeitung und Schulung? Diese Kosten gehören in die Rechnung.

Selbst schlechte UX hängt an einer Zahl. Messen lässt sie sich nicht bis auf die letzte Nachkommastelle, aber Leute aus dem Marketing werden dir bestätigen, dass schlechte UX die Abwanderung erhöht. Hältst du die UX eines Features für schlecht und hast einen guten Draht ins Marketing, kannst du dir dessen Fachwissen leihen. Gib dem Manager eine klare Aussage: Diese UX wird wahrscheinlich die Abwanderung erhöhen, sprich mit dem Marketing, bevor du sie freigibst.

Häufig gestellte Fragen

Warum reicht ein gemeinsames Fachvokabular nicht aus, damit sich Tester und Manager auf eine Veröffentlichung einigen können?

Weil die Meinungsverschiedenheit wirtschaftlicher Natur ist, nicht technischer. Beide Seiten können die Details besprechen und sind dennoch uneinig, sobald es um die Frage geht: „Jetzt veröffentlichen oder verschieben?“ Manager werden anhand von KPIs, OKRs und Umsatz gemessen, und die Hypothese eines Produktmanagers lautet, dass die sofortige Veröffentlichung der Funktion Nutzer und Geld bringt. Ein Tester, der ohne diesen Bezugsrahmen „Nein“ sagt, wirkt wie ein Gatekeeper.

Wie rechtfertigt man den Testaufwand, wenn in der Produktion nichts schiefgeht?

Betrachte es als Versicherung. Gute Qualitätssicherung sorgt für wenige oder gar keine Vorfälle, daher investiert das Team Aufwand und Zeit in Ereignisse, die nie eintreten, und genau das ist der Deal hinter einer monatlichen Versicherungsprämie. Tester können keine Null-Fehler-Garantie versprechen. Sie können die Wahrscheinlichkeit und die Auswirkungen von Schäden verringern, und Manager verstehen diesen Kompromiss bereits.

Was schützt einen Tester, wenn ein Manager ein dokumentiertes Risiko außer Kraft setzt?

Eine schriftliche Freigabe. Beschreibe das Risiko, nenne die wahrscheinlichen Kosten einer fehlerhaften Veröffentlichung und überlasse die Entscheidung dem Manager, anstatt aus Vertrauen heraus auf mehr Tests zu drängen. Die Entscheidung bleibt bei ihm. Ein Risiko, das ein Manager schriftlich akzeptiert hat, ist nichts, wofür der Tester später verantwortlich gemacht oder entlassen werden kann.

Welche Abteilungen liefern die Zahlen für einen Qualitäts-Business-Case?

Das Marketing kennt die Abwanderungsrate, die Kosten für die Kundenakquise und die Gründe, warum Kunden abwandern. Der Vertrieb kann entgangene Geschäfte beziffern: Wenn das Team 30 Prozent der Geschäfte gewinnt, frag nach, was es daran hindert, 50 Prozent zu erreichen. Customer Success kann die Stunden zählen, die damit verbracht werden, Nutzerbeschwerden in bestehende Fehlerberichte umzuwandeln. Der teaminterne Tracker zeigt, wie oft Funktionen aus dem Test zurück in die Entwicklung wandern.

Wo solltest du anfangen, wenn dein Terminkalender voll ist und niemand auf Argumente zur Qualität hört?

Bei der Verschwendung, die du bereits in deiner eigenen Arbeit siehst. Schließe dich mit dem einen oder den beiden Entwicklern zusammen, deren Funktionen immer wieder als nicht testbar zurückkommen, und klärt gemeinsam, wie sie programmieren. Entwickler mögen es nicht, wenn ihre Arbeit zurückgeschickt wird, das Interesse ist also gegenseitig. Zähle dann einfach die eingesparten Arbeitsstunden, zeige deinem QA-Leiter, dass die Zahlen stimmen, und bitte darum, den Aufwand zu skalieren.

Warum brennen Tester aus, die nur Testfälle abarbeiten?

Sich immer wieder durch dieselben Prüfschritte zu klicken, ohne den Überblick über das große Ganze zu haben, verwandelt den Job in eine seelenlose Routine, und Stolz auf die Arbeit braucht eine Verbindung zum Ergebnis. Regressionstests und explorative Tests führen einen Tester durch den gesamten Nutzerpfad, vom Abonnieren über den Kauf bis hin zur Kündigung, und genau daraus entsteht der Überblick über das Produkt.

Warum werden Vorschläge wie Pairing oder Mob Programming von Managern meist abgelehnt?

Sie kommen zu früh. Der Manager sieht darin eine Bedrohung für einen Prozess, dem er vertraut, und entgegnet, dass er nicht siebenmal für eine Funktion bezahlen will, und Argumente zu den Kosten der Verzögerung ändern daran nichts. Die Abfolge, die funktioniert: Direkte Verschwendung beseitigen, mit verifizierten Statistiken skalieren, den Ablauf verbessern, dann die teuren Maßnahmen vorschlagen. Beweise, dass du Geld sparen kannst, bevor du um Investitionen bittest.

Lässt sich eine schlechte UX finanziell begründen?

Ja, wenn auch nicht bis auf die letzte Dezimalstelle. Marketingfachleute werden bestätigen, dass eine schlechte UX zu einer höheren Abwanderungsrate führt. Ein Tester, der dort gute Kontakte hat, kann sich also auf dieses Fachwissen stützen, anstatt allein ein Modell zu erstellen. Die Aussage gegenüber dem Manager bleibt konkret: Diese UX wird wahrscheinlich die Abwanderungsrate erhöhen, sprich mit dem Marketing, bevor du sie freigibst.