Warum Manager/innen nicht auf Tester/innen hören

In der Testökonomie werden Entscheidungen über die Qualität von Software in finanzieller Hinsicht formuliert, damit Tester, Entwickler und Manager eine gemeinsame Sprache sprechen. Testen wird als Versicherung gegen kostspielige Fehlerwirkungen betrachtet, Verschwendung wie Nacharbeit und Kundenabwanderung werden quantifiziert und Qualitätsargumente werden in Zahlen umgewandelt, die Manager bereits kennen: verlorene Arbeitsstunden, nicht zustande gekommene Geschäftsabschlüsse und Kunden, die gehen, weil Fehler nicht behoben werden.

Das Wichtigste in Kürze

• Wenn der Testmanager sich über eine Risikowarnung hinwegsetzt, kann der Tester eine schriftliche Freigabe verlangen, die seinen Arbeitsplatz schützt.
• Die Verringerung sichtbarer, sich wiederholender Verschwendung (z. B. Funktionen, die vom Testen an die Entwicklung zurückgegeben werden, weil sie nicht getestet werden können) schafft die nötige Glaubwürdigkeit, bevor größere Investitionen in die Qualität vorgeschlagen werden.
• Tester haben einen direkteren Kontakt zum realen Nutzerverhalten als Produktmanager, da sie bei Regressions- und explorativen Tests den gesamten Weg des Nutzers von der Anmeldung bis zur Kündigung verfolgen müssen.
• Die Zeit, die der Kundensupport für die Weiterleitung von Nutzerbeschwerden in bestehende Fehlerberichte aufwendet, ist ein direkter, messbarer Kostenfaktor, der einen Business Case für eine bessere QS begründen kann, ohne dass eine komplexe Finanzmodellierung erforderlich ist.

Warum Tester und Manager ständig aneinander vorbeireden

Tester und Manager sprechen oft die gleiche Sprache und verstehen sich trotzdem nicht. Sie können die technischen Details besprechen. Die Uneinigkeit zeigt sich, sobald eine Release-Entscheidung auf dem Tisch liegt: mehr testen oder weniger testen, jetzt ausliefern oder verschieben.

Vitaly Sharovatov hat mehr als zwei Jahrzehnte in der IT-Branche verbracht, als Auftragnehmer und als Festangestellter, und hat beobachtet, wie sich diese Kluft in einem Unternehmen nach dem anderen auftat. Die Diskussionen über die Freigabe waren voreingenommen oder meinungsbildend. Ein Tester mit hohem Ansehen im Unternehmen konnte einfach sagen: “Ich gebe das nicht frei.” Ein Vorgesetzter konnte die Freigabe aber auch einfach durchsetzen.

Die Grundursache dafür ist ein fehlender gemeinsamer Rahmen. Manager werden an wirtschaftlichen Maßstäben gemessen, an KPIs, OKRs, Umsätzen. Die Hypothese eines Produktmanagers ist, dass die Veröffentlichung einer Funktion jetzt Nutzer, Wert und Geld bringt. Wenn der Tester Nein sagt, fängt der Manager an, den Tester als Gatekeeper zu sehen.

Vitaly hat erlebt, wie Tester wegen dieser wiederkehrenden Missverständnisse gestritten, gekündigt und gefeuert wurden. Erzwungene Freigaben können auch in die andere Richtung gehen, wenn Manager Risiken ignorieren, auf die Tester und Entwickler hingewiesen haben. Sein Fazit: Tester sollten zumindest lernen, die Sprache zu sprechen, die Manager bereits verwenden.

Testen als Versicherung behandeln, nicht als Kosten

Gute QS führt zu einem seltsamen Paradoxon. Wenn das Testen gut gemacht ist, gibt es in der Produktion keine oder nur sehr wenige Zwischenfälle. Du bezahlst mit Aufwand und Zeit für Dinge, die nie passieren.

Genau so funktioniert eine Versicherung, und jeder Manager versteht das bereits. Bei einer Krankenversicherung zahlst du jeden Monat für einen Vorfall, den du hoffentlich nie haben wirst. Brichst du dir in den USA ohne Versicherung ein Bein, landet die Rechnung in voller Höhe bei dir.

Investitionen folgen der gleichen Logik: Du zahlst jetzt für ein besseres Ergebnis später. Tester können nicht garantieren, dass es keine Bugs oder Zwischenfälle gibt. Was sie tun können, ist, ein Modell zu entwickeln, das den Schaden, die Auswirkungen oder die Wahrscheinlichkeit, dass den Nutzern etwas Schlimmes passiert, verringert.

Wenn man die Arbeit auf diese Weise gestaltet, ändert sich das Gespräch. Anstatt zu sagen: “Vertrau mir, wir brauchen mehr Tests”, beschreibst du das Risiko und die wahrscheinlichen Kosten einer schlechten Veröffentlichung und lässt den Manager entscheiden. Wenn du es schriftlich festhältst, muss er die Entscheidung absegnen. Das schützt auch den Tester. Ein Risiko, das der Vorgesetzte schriftlich akzeptiert hat, kann der Tester später nicht einfach ablehnen.

Wo die Zahlen schon stehen

Die finanziellen Argumente für Qualität liegen in anderen Abteilungen und warten darauf, gesammelt zu werden. Tester müssen keine Zahlen erfinden. Sie müssen die richtigen Leute nach Daten fragen, die bereits vorhanden sind.

Die Regulierung ist der sauberste Ausgangspunkt, vor allem in Europa. Das erste Risiko, das es zu benennen gilt, ist einfach: Was passiert, wenn das Unternehmen von Regierungsbeamten geschlossen wird? In den meisten Fällen hört der Geldfluss auf und das Unternehmen kommt zum Stillstand. Manager/innen begreifen dieses Risiko sofort, denn die Nichteinhaltung der Konformität kann das Aus für das Unternehmen bedeuten.

Das Marketing ist die nächste Ebene. Die Abwanderung, die Kosten für die Gewinnung eines Kunden und die Gründe, warum Kunden das Unternehmen verlassen, sind allesamt messbar. Wenn das Unternehmen im letzten Jahr eine Million Dollar verloren hat, weil Kunden das Produkt nicht mehr nutzen, hätte man etwas besser machen können. Manchmal ist dieses Etwas eine Funktion. Oft sind es UX, Bugs oder Support-Tickets, die monatelang unbeantwortet blieben.

Der Vertrieb kann die verlorenen Geschäfte quantifizieren. Wenn das Team 30 Prozent seiner Aufträge gewinnt, frage dich, was es daran hindert, 50 Prozent zu gewinnen. Ein Teil des 20-prozentigen Rückstands kann auf die Qualität zurückzuführen sein. Der Kundenerfolg kann dir sagen, wie viel Zeit er mit der Bearbeitung von Anfragen verbringt, die sich als Fehlerberichte herausstellen.

Dein eigenes Tracking-System trägt den letzten Teil bei. Ziehe die Jira-Statistiken heran und sieh dir an, wie oft Funktionen vom Testen zur Entwicklung zurückkehren. Wenn die Hälfte von hundert Funktionen zurückgeschickt wird, kannst du die verlorene Zeit und die Kosten für die Wiederholung dieser Arbeit berechnen. Für Produktmanager/innen ist das wichtig, weil sie wissen wollen, wie schnell eine Idee auf den Markt kommt und wie schnell sie von den Leuten genutzt werden kann.

Tester kennen die Nutzer besser als jeder andere

Tester haben eine analytische Gewohnheit, die zu dieser Arbeit passt. Sie bekommen ein Objekt zur Prüfung, ein Feature, einen Pull Request, und ihre Aufgabe ist es, es auseinanderzunehmen. Wenn sie genug Zeit mit einem Produkt verbracht haben, verstehen sie die Nutzer oft besser als die Produktmanager.

Produktmanager können in eine Version des Produkts abdriften, in der jede Funktion geliebt und gebraucht wird. Tester sehen die Fehlerberichte jeden Tag. Sie lesen direktes Feedback von echten Nutzern, so wie es auch der Kundenerfolg tut.

Regressionstests und explorative Tests zwingen die Tester, sich in die Lage der Nutzer/innen zu versetzen. Sie gehen den gesamten Weg: abonnieren, kaufen, nutzen, kündigen. Das macht sie zu guten Kandidaten, um sich einen Überblick darüber zu verschaffen, was tatsächlich mit dem Produkt passiert.

Tester, die nur Testkonzepte abarbeiten und Testfälle abhaken, neigen zum Ausbrennen. Sich durch die immer gleichen Prüfungen zu klicken, ohne einen Blick für das große Ganze zu haben, macht den Job zu einer seelenlosen Routine. Die Menschen wollen stolz auf ihre Arbeit sein, und Stolz braucht eine Verbindung zum Ergebnis.

Beginne mit dem Abfall, den du schon sehen kannst

Wenn dein Terminkalender voll ist und niemand zuhört, solltest du nicht mit der idealistischen Version beginnen. Der saubere Ansatz, bei dem Marketing, Vertrieb und Manager in einen Raum eingeladen werden, um ihre Ängste zu quantifizieren und sich darüber zu verständigen, inwieweit das Testen diese Risiken verringert, funktioniert in einigen Unternehmen. In vielen wird dir der Manager einfach sagen, du sollst zurück zum Testen gehen.

Geh also in kleinen Schritten vor. Beginne damit, deine eigene Arbeit auf sich wiederholende, verschwenderische Anstrengungen zu analysieren. Das zahlt sich fast immer aus.

Wenn ein Entwickler dir immer wieder Funktionen liefert, die nicht testbar sind oder nicht funktionieren, tausche dich mit ihm aus. Frag ihn, wie du ihm helfen kannst, sie richtig zu bauen. Entwickler/innen mögen es nicht, wenn Funktionen zurückgeschickt werden, also ist es in eurem gemeinsamen Interesse, wenn ihr euch darüber abstimmt, wie sie funktionieren. Wenn du das mit zwei oder drei Entwicklern machst, werden die wiederholten Runden des Testens und der Nacharbeit immer kleiner.

Dann sammle die Zahlen. Für diesen ersten Schritt brauchst du weder die Zeit bis zur Markteinführung noch die Kosten der Verzögerung. Einfache Arbeitsstunden reichen aus. Zeige deinem QS-Leiter, wie viele Stunden du und deine Kollegen eingespart habt, beweise, dass die Zahlen stimmen, und bitte darum, den Aufwand zu erhöhen.

“Beginne mit den direkten Kosten, die zu 100 % Verschwendung sind, von denen du weißt, dass sie Verschwendung sind, die du als Verschwendung empfindest.” Vitaly Sharovatov

Verschaffe dir Glaubwürdigkeit, bevor du die riskanten Veränderungen vorschlägst

Die Reihenfolge ist wichtig. Indem du offensichtliche Verschwendung reduzierst, verschaffst du dir die nötige Berechtigung, bevor du einem Manager etwas vorschlägst, das ihm riskant erscheint.

Wenn du in das Büro eines Managers gehst und vorschlägst, Einzelarbeit durch Mobbing zu ersetzen, ist die Antwort vorhersehbar: “Ich zahle doch nicht sieben Mal für eine Funktion.” Argumente über die Kosten der Verzögerung oder die Zeit bis zur Markteinführung werden nicht ziehen, weil die Führungskraft darin eine Bedrohung für den Prozess sieht, den sie kennt und dem sie vertraut.

Die Reihenfolge, die funktioniert, sieht so aus:

Wenn du zu den risikoreicheren Vorschlägen kommst, hast du bereits bewiesen, dass du Geld sparen kannst. Erst wenn du bewiesen hast, dass du Geld sparen kannst, kannst du glaubhaft verlangen, Geld in Qualität zu investieren.

Win-Win schlägt die Berechtigung jedes Mal

Eine Veränderung durch Autorität zu erzwingen, bringt selten etwas, denn die Menschen hängen an der Arbeit, in die sie investiert haben. Ein Entwickler, der zwei Monate an einem Feature gearbeitet hat, wird es nicht gut finden, wenn ein Tester es mit zwanzig Fehlerzuständen in einem Aufzählungspunkt zurückgibt.

Dieser Sunk-Cost-Reflex ist real und erfahrene Entwickler wissen das. Die Chance, dass ein Feature, an dem zwei Monate gearbeitet wurde, beim ersten Versuch bestanden wird, ist so gut wie null. Deshalb geben erfahrene Entwickler ihre Arbeit viel häufiger und in kleineren Teilen an die Tester weiter.

Die Funktion zurückzubringen funktioniert, aber es ist besser, sich danach mit dem Entwickler zusammenzusetzen und eine Win-Win-Situation zu finden. Wenn beide Seiten mit dem Ergebnis zufrieden sind, gewinnen deine Initiativen Verbündete, die dich vor der Geschäftsführung unterstützen werden.

Das gleiche Prinzip gilt auch nach oben hin. Manager/innen berichten ihren Vorgesetzten über die Ergebnisse in Form von Zahlen. Wenn du einem Manager hilfst, bessere Zahlen zu melden, wirst du für ihn wertvoller. Sie werden sagen, dass sie das Projekt gerettet haben und dass du geholfen hast, und das ist gut so, denn sie wissen, dass du geholfen hast.

Wirtschaft bedeutet nicht, alles in eine Tabelle zu verwandeln

Ein häufiger Einwand ist, dass ökonomisches Denken alles auf Zahlen reduziert. Das stimmt nicht. Qualitative Urteile bleiben im Bild; die Zahlen geben ihnen Gewicht.

Jedes Unternehmen hat seine eigene Situation. Du kannst einen Ansatz nicht übernehmen, nur weil Amazon ihn verwendet, genauso wie ein erfahrener Entwickler eine Umstellung von Angular auf React in Frage stellt, indem er fragt, wo die wirtschaftliche Rechtfertigung liegt. Beim Testen gibt es den gleichen Impuls, ein Framework gegen ein anderes auszutauschen, und er verdient die gleiche Frage.

Wirtschaftlich zu denken bedeutet auch, an die Menschen zu denken. Kennt ein Kollege oder eine Kollegin das neue Framework oder erfordert der Wechsel ein Onboarding und eine Schulung? Diese Kosten gehören in die Kalkulation.

Auch eine schlechte UX ist mit einer Zahl verbunden. Sie lässt sich zwar nicht bis auf die letzte Nachkommastelle messen, aber Marketingexperten werden dir sagen, dass schlechte UX zu einer höheren Abwanderung führt. Wenn du die UX eines Features als schlecht bewertest und eine Arbeitsbeziehung mit dem Marketing hast, kannst du dir dessen Fachwissen zu Nutze machen. Gib dem Manager ein klares Statement: Diese UX wird wahrscheinlich die Abwanderung erhöhen, sprich mit dem Marketing, bevor du es absegnest.