Wie man Tests in großen Konzernen besteht: Praxisfälle
Der Wechsel in ein neues Büro gleicht oft einem Sprung in eine völlig andere Realität. Statt des gewohnten Open Space mit zehn Kollegen erwartet einen eine ganze Etage für dreihundert Personen. Statt eines einzelnen Produkts gibt es zehn vernetzte Systeme, jedes mit eigener API, Datenbank und eigenem Entwicklerteam. Zu allem Überfluss kommt noch Legacy-Code hinzu, der vor acht Jahren geschrieben wurde und den niemand anzurühren wagt, weil die Angst vor Fehlern zu groß ist.
Für viele Tester ist ein solcher Wechsel ein Schock. Nicht, weil sie schlechte Fachkräfte wären. Sondern weil die Unternehmensumgebung eine völlig andere Arbeitsweise erfordert.
Wie unterscheidet sich das Testen im Konzern von der Arbeit im Startup
Im Startup bist du für ein kleines Produkt verantwortlich. Das Team ist klein, die Kommunikation direkt, Releases erscheinen täglich. Wenn etwas kaputt geht – wird es in einer Stunde repariert.
Im Konzern ist alles anders. Dein Produkt wird von Hunderttausenden Menschen genutzt. Ein Fehler in der Berechnungslogik kann das Unternehmen Millionen kosten. Das Release-Fenster ist alle zwei Wochen, und wenn du es nicht schaffst, wartest du auf das nächste. Die Codebasis ist riesig, und niemand kennt sie vollständig.
Stell dir vor, du testest ein Online-Banking. Im Startup wäre das eine App zum Geldtransfer zwischen Karten. Im Konzern ist es ein System, das mit dem Processing, CRM, Anti-Fraud, Steuerberichten und einem Dutzend weiterer Dienste verbunden ist. Du überprüfst eine Überweisung, und sie schlägt fehl, weil im benachbarten Modul das Datenformat aktualisiert wurde.
Der Hauptunterschied: Im Konzern arbeitest du selten allein. Du bist Teil eines komplexen Mechanismus, bei dem jede deiner Handlungen andere beeinflusst.
Die erste Falle: Angst vor einer komplexen Infrastruktur
Neue Tester in Konzernen sind oft überfordert. Sie sehen hunderte Tests, dutzende Umgebungen, CI/CD-Pipelines, eine Menge Logs und Monitorings. Der Gedanke kommt: „Ich werde mich darin nie zurechtfinden."
Tatsächlich musst du nicht alles auf einmal verstehen. Im Konzern gilt das Prinzip der Abstraktionsebenen. Du musst nicht wissen, wie jedes Modul funktioniert. Es reicht, die Schnittstellen zwischen ihnen zu verstehen.
💡 Rat: Wenn du in einen neuen Konzern kommst, fang mit einem Bereich an. Wähle einen Microservice oder eine Funktionalität. Analysiere sie vollständig: von der Oberfläche bis zur Datenbank. Sobald du sie verstanden hast, gehe zu den verbundenen Systemen über. Nach und nach ergibt sich das Gesamtbild von selbst.
Ein typischer Fehler ist zu versuchen, alles in einem Monat zu lernen. Das führt zum Burnout. Unternehmenscode wächst über Jahre. In zwei Wochen ist er nicht zu bewältigen. Gib dir Zeit.
Kommunikation im großen Team: Wie man nicht den Überblick verliert
Im Konzern kommunizierst du nicht nur mit Entwicklern. Es gibt Analysten, Produktmanager, DevOps-Ingenieure, Tech Leads, Architekten, Manager aus benachbarten Teams. Und jeder hat seine eigene Sprache, Prioritäten und Deadlines.
Das Problem entsteht, wenn sich der Tester auf seine Aufgabe konzentriert und den Blick für das Ganze verliert. Zum Beispiel findest du einen Bug. Für dich ist es ein offensichtliches Problem. Aber der Entwickler sagt: „Wir haben andere Prioritäten, das ist nicht kritisch." Es kommt zum Konflikt.
💡 Rat: Im Konzern gewinnt derjenige, der seine technischen Anforderungen in die Sprache des Geschäfts übersetzen kann. Statt „dieser Bug unterbricht die Feldvalidierung" sag: „Dieser Bug führt dazu, dass 5 % der Nutzer die Registrierung nicht abschließen können, was zu einem Verlust von 2000 Leads pro Tag führt." Zahlen verändern die Wahrnehmung.
Eine weitere Falle ist die Kommunikation in Chats. Im Konzern kannst du dutzende Chats haben: zum Projekt, zur Automatisierung, zu Releases, zur Infrastruktur. Es ist leicht, darin unterzugehen. Eine einfache Regel: Wenn die Diskussion länger als fünf Nachrichten dauert und zu keiner Lösung führt – geh in den Voice-Kanal. Ein 10-minütiger Videoanruf löst, was im Chat eine Stunde diskutiert wird.
Der Weg vom manuellen Test zur Automatisierung
Im Konzern ist manuelles Testen nicht die ganze Arbeit, sondern nur ein Teil davon. Mit der Zeit wirst du unweigerlich auf die Notwendigkeit stoßen, Prüfungen zu automatisieren. Warum? Weil manuelles Regressionstesten eine Woche dauern würde, aber ein Release alle zwei Wochen erfolgen muss. Automatisierung ist der einzige Weg, die Qualität bei diesem Tempo zu halten.
Es gibt jedoch einen Haken. In Konzernen werden oft Legacy-Technologien verwendet. Zum Beispiel alte Software auf Java 8 mit monolithischer Architektur. Das zu automatisieren ist schwierig. Vieles muss „in Produktion" oder über Monitoring getestet werden.
In einer Bank fiel unser Test für Überweisungen von Karte zu Karte aus, weil wir keine Testumgebung mit echtem Processing hatten. Wir haben es so gemacht: Wir schrieben einen Test, der eine Transaktion generiert, und überprüften nach dem Release die Logs des Processing. Wenn die Transaktion nicht innerhalb von 30 Sekunden durchlief – Bug. Das ist ein untypischer Ansatz, aber er funktionierte.
Berufliches Burnout: Wie man nicht aus dem Beruf ausscheidet
Konzerne sind auf die lange Distanz ausgelegt. Du läufst keinen Sprint, du läufst einen Marathon. Wenn du jeden Tag 120 % gibst, ist deine Energie nach einem halben Jahr erschöpft.
Die Symptome von Burnout bei Testern sind besonders. Du beginnst, Bugs zu übersehen. Oder du hörst auf, an den Wert deiner Arbeit zu glauben. Oder du wirst zynisch: „Das braucht sowieso niemand, Hauptsache der Release kommt raus."
💡 Rat: Um einem Burnout vorzubeugen, führe drei Regeln ein: - Bestimme deine „Bug-Norm". Du kannst nicht alle Bugs in jedem System finden. Akzeptiere das. - Erhole dich vom Bildschirm. Öffne nach der Arbeit mindestens eine Stunde lang keinen Laptop. - Wechsle die Art der Tätigkeit. Wechsle zwischen manuellem Testen und Automatisierung, Log-Analyse und Dokumentation, Teamkommunikation und selbstständiger Arbeit.
In Konzernen leiden Tester oft unter Hyperverantwortung. Sie haben das Gefühl, dass das Produkt zusammenbricht, wenn sie einen Bug übersehen. Aber die Realität ist: Das Produkt bricht zusammen, wenn das gesamte Team – Entwickler, Analysten, DevOps, Tester – einen Fehler macht. Du bist nicht allein.
Wie man ein Architekt von Testlösungen wird
Architekt von Testlösungen – das ist eine Rolle, die man nach 5-7 Jahren Arbeit in Konzernen erreicht. Es ist nicht einfach ein „Senior Tester". Es ist eine Person, die das gesamte Testsystem entwirft: von der Auswahl der Tools bis zur Testabdeckungsstrategie.
Was man können muss:
- Die Produktarchitektur auf der Ebene von Diensten, Datenbanken, Nachrichten-Warteschlangen verstehen.
- Tools nicht „weil es modern ist" auswählen, sondern für konkrete Aufgaben. Zum Beispiel reichen für das Testen von Microservices oft Vertragstests, und E2E-Tests sind nur für kritische Szenarien nötig.
- Die Wirtschaftlichkeit berechnen können. Ein Architekt muss der Geschäftsleitung erklären können: „Wenn wir 300 Stunden in die Automatisierung dieses Moduls investieren, sparen wir in einem halben Jahr 500 Stunden manuelles Testen."
- Testumgebungen entwerfen, die nicht jeden Tag ausfallen.
💡 Rat: Um Architekt zu werden, fang mit einem Schritt an: Geh über dein Modul hinaus. Sieh dir an, wie das gesamte System aufgebaut ist. Wo sind die Engpässe? Was fällt am häufigsten aus? Welche Tests sind doppelt? Sobald du das Gesamtbild verstehst, kannst du Verbesserungen vorschlagen.
Praxisbeispiel: Wie wir das Testen in einem Fintech-Konzern aufbauten
Angenommen, du landest in einem Unternehmen mit fünf Teams, die jeweils ihren eigenen Microservice schreiben. Das Produkt ist ein Zahlungs-Gateway. Jedes Team testet sein Modul isoliert. Für die Integration bleiben zwei Tage vor dem Release. Und jedes Mal geht etwas kaputt.
Was ist das Problem? Es gibt keine gemeinsame Teststrategie. Keine Integrationstests. Kein Verständnis dafür, wie die Module miteinander interagieren.
Was wir gemacht haben:
- Wir führten Vertragstests für jede API ein. Jetzt können Teams keinen Endpunkt mehr ändern, ohne die anderen zu benachrichtigen.
- Wir schrieben einen gemeinsamen Smoke-Test, der die Kette überprüft: Benutzer → Zahlung → Bestätigung → Eintrag in den Verlauf.
- Wir machten eine obligatorische Regression vor jedem Release, automatisierten aber nur die kritische Funktionalität. Nebenläufige Fälle ließen wir für manuelles Testen.
- Wir führten Fehlerüberwachung in der Produktion mit Telegram-Alarmen ein. Wenn nach einem Release die Anzahl erfolgreicher Zahlungen sinkt – wissen wir es sofort.
Die Falle des „perfekten Tests"
Viele Anfänger-Tester in Konzernen versuchen, einen perfekten Test zu schreiben. Er soll alle Fälle abdecken, stabil sein und in allen Umgebungen funktionieren. Am Ende verschwenden sie Wochen, aber der Test kommt nie in die Produktion.
💡 Rat: Ein guter Test ist kein perfekter Test. Es ist ein Test, der Bugs findet und dabei keine ständige Wartung erfordert. Wenn ein Test einmal im Monat aufgrund eines Flaky-Fehlers ausfällt, kann man ihn in 10 Minuten reparieren. Wenn er nie ausfällt, aber nur den Happy Path prüft – ist sein Wert gleich null.
Wie man vom Tester zum Prozessmanager wird
Nicht alle Tester wollen Architekten werden. Einige wählen den Management-Pfad: Team Lead, QA Lead, Test Manager.
Was sich ändert:
- Du testest weniger manuell und verwaltest mehr Menschen, Prozesse, Prioritäten.
- Du bist für Metriken verantwortlich: Coverage, Defect Leakage, Time-to-Release.
- Du löst Konflikte zwischen Teams, handelst Fristen aus, verteidigst das Budget für die Automatisierung.
💡 Rat: Wenn du in die Führung gehen willst, fang klein an: Übernimm die Durchführung von Retrospektiven. Lerne, Metriken zu sammeln und zu analysieren. Versuche dann, einen Testablauf zu leiten – zum Beispiel die Regression. Erweitere nach und nach deinen Verantwortungsbereich.
Wohin geht es weiter
Eine Karriere im Konzern ist keine Leiter, sondern ein System von Korridoren. Du kannst dich in die Technologie vertiefen, ein Experte für Leistung, Sicherheit oder Automatisierung werden. Du kannst ins Management wechseln. Du kannst Testberater werden.
Die Hauptsache ist, nicht stecken zu bleiben. Wenn du ein Jahr lang dasselbe tust und nicht wächst – ist es Zeit, etwas zu ändern: Projekt, Rolle oder Ansatz.
Denk daran: Der Konzern ist nicht für ideale Bedingungen da. Es geht darum, im Chaos zu arbeiten, zu verhandeln und Ergebnisse zu liefern. Wenn du das meisterst, wirst du unersetzlich.
