Der geschäftliche Nutzen des Testens zeigt sich in konkreten Zahlen: was Testen ein Unternehmen kostet und was es ihm einbringt, statt abstrakter Argumente über Qualität. Tester, die wissen, wie ihr Unternehmen Geld verdient, können Risiken in Geld umrechnen, etwa Regressionszeit, Supportkosten oder die Folgen eines fehlerhaften Releases. Erst diese Rechnung macht Testen für Entscheider sichtbar.
Das Wichtigste in Kürze
- Wer nicht erklären kann, was ein fehlgeschlagenes Release in Euro kostet, verliert die Budgetdiskussion, weil Manager Testen als abstrakten Kostenblock sehen und nicht als Werkzeug gegen Risiken.
- Ob sich Testautomatisierung rechnet, hängt von Wartungskosten und Lebensdauer ab: Ein Produkt zu automatisieren, das bald gestrichen oder stark umgebaut wird, vernichtet Wert.
- Ein Mitarbeiter kostet ein Unternehmen grob das Doppelte seines Bruttogehalts, wenn man Arbeitgeberabgaben, Zusatzleistungen, Zeiten ohne Projekteinsatz und Gemeinkosten mitrechnet.
- Tester sind selbst dafür verantwortlich, Qualitätsberichte zu liefern und Risiken aktiv anzusprechen, denn Kunden fragen nicht nach Informationen, von denen sie nicht wissen, dass sie sie brauchen.
- Wer versteht, wie ein Unternehmen Geld verdient, wer die wichtigsten Stakeholder sind und welche Entscheidungen sie treffen, kann Testergebnisse in geschäftlichen Nutzen übersetzen.
Warum Tester wissen sollten, wie ihr Unternehmen Geld verdient
Wer das Geschäft hinter der eigenen Arbeit versteht, trifft bessere Entscheidungen, gerade wenn Budgets knapp werden, und genau daran hängt der geschäftliche Nutzen des Testens. Marta Firlej beobachtet, dass viele Tester ihr Handwerk bis ins Detail beherrschen, aber kein Bild davon haben, wie ihr Unternehmen Geld verdient, wer die Stakeholder sind und welche Entscheidungen über das Budget bestimmen.
Am deutlichsten wird diese Lücke in der Krise. Wenn das Geld knapp wird, blenden Tester die finanzielle Seite ihrer Arbeit gern aus, obwohl sie genau dann am meisten zählt.
Unternehmen gibt es, um Geld zu verdienen. Marta erzählt, dass dieser schlichte Satz viele im Raum überrascht, wenn sie ihn so deutlich ausspricht. Jedes Unternehmen, jede Regierung, jedes Land arbeitet, um Geld zu verdienen. Testen ist Teil dieser Realität, ob Tester das wahrhaben wollen oder nicht.
Was ein Mitarbeiter wirklich kostet
Ein Mitarbeiter kostet ein Unternehmen weit mehr als sein Gehalt, und die meisten Tester unterschätzen das. Marta rechnet es vor: Sie beginnt beim Bruttogehalt und legt dann Schicht für Schicht drauf, was der Arbeitgeber tatsächlich trägt.
In Polen zahlt der Arbeitgeber rund 30 Prozent zusätzliche Abgaben auf das Bruttogehalt. Rechnest du das auf zwölf Monate hoch, hast du die Grundinvestition in eine Person. Als grobes Denkmodell verdoppelst du diesen Wert dann, um alles andere abzudecken, was das Unternehmen finanziert.
Zu diesem “alles andere” gehören Leistungen, bei denen kaum jemand an ein Preisschild denkt: Gesundheitsversorgung, Weiterbildung, Konferenztickets, sogar das Obst im Büro am Donnerstag. Nichts davon ist umsonst, und einzeln eingekauft wäre es teurer als das, was das Unternehmen durch die Menge zahlt.
Auch das Onboarding steht auf der Rechnung. Ein neuer Kollege verursacht Einarbeitungskosten, bevor er die erste Stunde abrechnet. Und wer zwischen zwei Projekten ohne Einsatz ist, bleibt trotzdem eine Investition, die das Unternehmen trägt.
Dazu kommen Leute, deren Gehälter alle anderen mittragen. Marta sagt es direkt: Das Gehalt der Führungskraft, das Gehalt der Kollegen ohne Projekt, das Budget für Schulungen und die Teamfeier müssen die abrechenbaren Leute verdienen. Auf die sichtbaren Kosten kommen mindestens 40 Prozent obendrauf, denn das Unternehmen ist dazu da, Gewinn zu machen.
Welchen Wert Testen für Stakeholder hat
Testen bringt geschäftlichen Nutzen, wenn es Stakeholdern sagt, wie viel Geld sie verlieren können, und nicht nur, wie gut die Qualität ist. Marta zieht eine klare Linie zwischen den Informationen, die Tester ohnehin liefern, und dem, worauf ein Stakeholder tatsächlich achtet.
“Hier sind Informationen zur Qualität” bleibt in der Welt der Tester. “So viel Geld verlierst du, wenn du jetzt releast” ist die Sprache des Geschäfts. Gute Produktmanager können diese Rechnung aufmachen, und Tester sollten ihnen dabei helfen.
Testen verkauft sich anders als Entwicklung. Wofür sie bei der Entwicklung bezahlen, haben die Leute längst gelernt: Sie sehen Codezeilen und Features, die funktionieren. Was Qualität kostet oder wie das Risiko aussieht, wenn man auf sie verzichtet, hat ihnen niemand beigebracht. Diese Argumente müssen Tester selbst liefern.
Wer seine Arbeit nicht so darstellt, wie Stakeholder sie brauchen, bekommt keine Anerkennung dafür. Marta formuliert es ohne Umschweife: Entweder du vertrittst deine Arbeit in der Sprache des Unternehmens, oder du schaust zu, wie sie als verzichtbarer Kostenposten behandelt wird.
Warum Testen in der Krise als Erstes gestrichen wird
Testen wird zuerst gekürzt, weil es als abstrakter Kostenblock für ein künftiges Risiko gilt und nicht als sichtbares Ergebnis. Viele Manager können sich unter Testen wenig vorstellen, also lässt es sich leicht streichen.
Marta hat dieses Muster mehrfach erlebt. In rund 20 Jahren auf dem polnischen Testmarkt hat sie vier Krisen mitgemacht, in denen Kunden Aufträge aus Kostengründen von Polen nach Indien verlagert haben. Viermal mussten Tester ihren Wert mit demselben Argument beweisen.
Risiko in Geld umrechnen
Die Antwort darauf ist, Risiko in Geld auszudrücken. Eine vollständige Regression, die eine Woche dauert, lässt sich als Kostenposten aufschreiben. Rund-um-die-Uhr-Support über die Feiertage, weil niemand der Funktionalität traut, hat einen Preis. Übersprungene QS-Prozesse ebenso.
Diese Zahlen haben Tester meist nicht allein in der Hand. Product Owner, Projektleiter und Engineering Manager sitzen näher am Budget und kennen es besser. Die Aufgabe des Testers: das Gespräch anstoßen, das Risiko in Zahlen benennen und das Team informieren, auch wenn am Ende jemand anderes entscheidet.
Wann sich Testautomatisierung nicht rechnet
Testautomatisierung lohnt sich nur, wenn das Getestete lange genug lebt, um Aufbau und Wartung wieder einzuspielen. Marta nennt sich selbst bewusst faul, was ihre Zeit angeht: Sie steckt sie nur dorthin, wo sie echten Nutzen bringt.
Entscheidend ist die Stabilität. Bei einem Proof of Concept, einem Produkt, das sich schnell ändert, oder einer Lösung für eine kleine Nutzergruppe ist eine komplette Regressionsautomatisierung selten sinnvoll. Produkt oder Anforderungen ändern sich wahrscheinlich, bevor sich die Tests bezahlt machen. Smoke-Tests und die wirklich kritischen Pfade lohnen sich. Der Rest kann warten.
Sie kennt beide Enden aus der eigenen Arbeit. In der Finanzbranche bleiben manche Funktionen jahrelang bestehen und rechtfertigen die Investition. Andere sind Experimente: Gefallen sie den Nutzern nicht, fliegt das Feature raus, und alle Tests, die darum herum gebaut wurden, gleich mit.
Ein typischer Planungsfehler lässt Automatisierung billiger aussehen, als sie ist. Teams entwerfen eine Automatisierungsstrategie und kalkulieren die Erstellung, vergessen aber die Wartung: Wer hält die Tests am Laufen, und wie oft? Marta macht die ganze Entscheidung am Return on Investment fest und stellt fest, dass er oft nicht reicht.
Ein Projektwechsel schärft das Urteil
Wer zwischen Projekten und Unternehmen wechselt, wird ein besserer Tester und löst sich von der emotionalen Bindung an die eigene Arbeit. Marta sieht ein echtes Risiko darin, zu lange an einer Codebasis oder einem Framework zu hängen.
Engineers verlieben sich in die Frameworks und Automatisierungen, die sie bauen, und können sie dann nicht mehr loslassen. Je länger du bleibst, desto mehr fühlt sich die Arbeit an wie dein Kind, und Kritik daran trifft dich persönlich.
Sie erzählt von einem Testautomatisierer, der bei den Bewerbungsgesprächen für seine eigene Nachfolge dabei war. Jeder Kandidat sah sich einen seiner Testfälle an und erklärte, was er besser machen würde. Nach dem dritten Gespräch bat er, aufzuhören. Die Kandidaten hatten recht, er hatte diese Fehler gemacht und hätte es günstiger und wartbarer bauen können. Es zu hören, fühlte sich trotzdem an, als würde jemand sein Kind angreifen.
Die Lehre daraus: einen Kontextwechsel als Chance zum Lernen sehen, nicht als Zerstörung. Jedes neue Projekt und jedes neue Unternehmen bringt etwas mit, und der Abstand hält dein Urteil ehrlich.
So rechnest du den geschäftlichen Nutzen des Testens aus
Für den Anfang reichen ein Blatt Papier und dein eigenes Gehalt. Marta schlägt eine Reihenfolge vor, die jeder Tester allein durchgehen kann:
- Starte mit deinem Gehalt und finde heraus, wie Verträge und Arbeitsverhältnisse in deinem Land funktionieren.
- Rechne die Zusatzkosten des Arbeitgebers dazu. In Polen sind das rund 30 Prozent auf das Bruttogehalt.
- Multipliziere mit zwölf Monaten. Das ist die jährliche Investition in dich.
- Addiere alle Zusatzleistungen: Gesundheitsversorgung, Schulungen, Konferenztickets, die kleinen Extras im Büro.
- Nimm die übrigen Aktivitäten des Unternehmens dazu: Markenaufbau, Marketing, Investitionen, Spenden.
- Schlag mindestens 40 Prozent drauf, denn das Unternehmen ist dazu da, Geld zu verdienen.
Danach schaust du dir an, wie dein Unternehmen als Betrieb funktioniert. Gibt es Leute ohne Projekt? Wie viele arbeiten dort, ohne abzurechnen? Wer sind die wichtigsten Stakeholder, woher kommt das Unternehmen, und wohin will es?
Über Geld zu reden fällt vielen schwer. Marta sagt offen, dass man in Polen nicht dazu erzogen wird, darüber zu sprechen, es ist fast ein Tabu. Ihre Ermutigung ist einfach:
“Hab keine Angst, du bist nicht allein. Wir stecken alle mit drin, solange wir Arbeit haben.”
(Marta Firlej)
Häufig gestellte Fragen
Was übersehen Tester am häufigsten in Bezug auf ihr eigenes Unternehmen?
Viele Tester verstehen das Testen zwar bis ins Detail, haben aber keine Vorstellung davon, wie ihr Arbeitgeber eigentlich Geld verdient, wer die wichtigsten Stakeholder sind oder welche Entscheidungen das Budget beeinflussen. Marta Firlej beobachtet, dass sich diese Kluft gerade dann vergrößert, wenn es am wichtigsten ist: In einer Krise neigen Tester dazu, die finanzielle Seite ihrer Arbeit zu ignorieren, genau in dem Moment, in dem die Geschäftsleitung entscheidet, was überlebt.
Wie viel kostet ein Mitarbeiter ein Unternehmen wirklich, abgesehen vom Gehalt?
Etwa das Doppelte des Bruttogehalts ist ein brauchbares Denkmodell. In Polen zahlt der Arbeitgeber zusätzlich zum Bruttogehalt etwa 30 Prozent an weiteren Steuern, multipliziert mit zwölf Monaten. Hinzu kommen Krankenversicherung, Fortbildungen, Konferenzteilnahme, Bürovergünstigungen, Einarbeitungskosten und Leerlaufzeiten zwischen Projekten. Rechne mindestens 40 Prozent mehr hinzu, da Manager, nicht abrechnungsfähige Kollegen und der Gewinn von den abrechnungsfähigen Mitarbeitern erwirtschaftet werden müssen.
Warum müssen Tester ihr Budget rechtfertigen, während Entwicklungsausgaben unhinterfragt bleiben?
Die Leute haben schon vor langer Zeit gelernt, warum sie für die Entwicklung bezahlen: Sie sehen Codezeilen und funktionierende Features. Niemand hat ihnen jemals beigebracht, was Qualität kostet oder wie das Risiko aussieht, wenn man sie außer Acht lässt. Diese Asymmetrie bedeutet, dass Tester ihre Argumente selbst aufbauen müssen. Arbeit, die nicht in geschäftlichen Begriffen gefasst wird, wird als optionaler Kostenfaktor behandelt.
Was kann ein Tester tun, wenn das Management plant, das QA-Budget zu kürzen?
Setze das Risiko in Zahlen um. Eine vollständige Regression, die eine Woche dauert, hat ihren Preis. Rund-um-die-Uhr-Support über die Feiertage, der nötig ist, weil niemand der Funktionalität traut, hat seinen Preis. Auch ausgelassene QA-Prozesse haben ihren Preis. Tester verfügen selten allein über diese Zahlen, daher besteht die Aufgabe darin, das Gespräch mit Product Ownern und Projektmanagern zu suchen, und nicht, die Entscheidung zu treffen.
Lohnt sich die Automatisierung der kompletten Regressionssuite immer?
Nein. Automatisierung zahlt sich nur dann aus, wenn das zu testende Produkt lange genug im Einsatz bleibt, um die Entwicklungskosten plus Wartungskosten wieder hereinzuholen. Bei einem Proof of Concept, einem sich schnell verändernden Produkt oder einer Funktion für eine kleine Nutzergruppe macht eine vollständige Regressionstest-Automatisierung selten Sinn, da sich die Anforderungen ändern, bevor die Tests einen Nutzen bringen. Smoke-Tests und wirklich kritische Pfade lohnt es sich weiterhin zu automatisieren.
Was ist der häufigste Fehler bei einem Business Case für Automatisierung?
Teams berechnen die Entwicklungskosten und lassen die Kosten der Wartung außer Acht. Niemand legt fest, wer die Tests am Laufen hält und wie oft, daher sieht die Automatisierung auf dem Papier günstiger aus, als sie es tatsächlich ist. Im Finanzdienstleistungsbereich bleiben manche Funktionen jahrelang bestehen und rechtfertigen die Ausgaben. Experimentelle Funktionen werden gestrichen, und jeder Test, der darauf aufbaut, wird mit ihnen gelöscht.
Macht es einen Tester schlechter, wenn er jahrelang am selben Projekt arbeitet?
Das birgt ein echtes Risiko. Engineers verlieben sich in die Frameworks und die Automatisierung, die sie selbst entwickeln, und weigern sich dann, sie loszulassen, bis Kritik am Code sich wie Kritik an ihnen selbst anfühlt. Ein Automatisierungsentwickler war bei Vorstellungsgesprächen für seinen eigenen Nachfolger dabei, hörte sich an, was die Kandidaten verbessern würden, und hörte nach dem dritten auf. Sie hatten recht, und es tat trotzdem weh.
Wie kann ein Tester anfangen, seinen eigenen geschäftlichen Wert einzuschätzen?
Nimm ein Blatt Papier und dein Gehalt zur Hand. Informiere dich, wie Verträge und Arbeitsverhältnisse in deinem Land funktionieren, rechne die zusätzlichen Kosten des Arbeitgebers dazu, multipliziere das Ganze mit zwölf Monaten und füge dann alle Zusatzleistungen hinzu: Krankenversicherung, Fortbildungen, Konferenzkarten, kleine Vergünstigungen im Büro. Rechne Branding, Marketing und Spenden hinzu, dann mindestens 40 Prozent Gewinn. Schau dir danach die Ausfallzeiten, die nicht abrechenbaren Personalkosten und die Stakeholder an.
