Enterprise-Testing: Wie du nicht in der „manuellen Sklaverei“ stecken bleibst und zum Architekten aufsteigst

Jahre im Dienst auf einem kleinen Fischerboot lehrten mich, jeden Riss im Deck zu kennen, den Motor selbst zu reparieren und intuitiv zu spüren, wo die Fische beißen. Doch diese Erfahrung erfordert nun ein völliges Umdenken: Ich stehe auf der Brücke eines riesigen Containerschiffs mit hunderten Besatzungsmitgliedern, hochkomplexen automatisierten Navigationssystemen und einem Fahrplan, der an Häfen in verschiedenen Zeitzonen gebunden ist.

Ungefähr so fühlt sich der Wechsel von einem kleinen Studio zu einem großen Enterprise an.

Hier funktioniert das Prinzip „Bug gefunden – behoben – weitermachen“ nicht. Im Großkonzern managst du die Qualität eines Produkts, das von Millionen genutzt wird. Und dein wichtigstes Werkzeug sind weniger technische Fähigkeiten als vielmehr systemisches Denken.

Was im Enterprise wirklich passiert

In kleinen Projekten siehst du das gesamte Bild. Du kannst an einem Tag durch alle Anwendungsschichten gehen, Mocks hochziehen, Testdaten einspielen und sagen: „Hier ist es kaputt, repariert es.“

Im Großkonzern ist das Bild anders. Deine Aufgabe ist es nicht nur, einen Defekt zu finden, sondern zu beweisen, dass er existiert, ihn in der richtigen Umgebung zu reproduzieren, korrekt zu klassifizieren und das Entwicklungsteam davon zu überzeugen, dass dies eine höhere Priorität hat.

Der Unterschied liegt im Verantwortungsmaßstab. Davon, wie richtig du die Grundursache ermittelst, hängen der Veröffentlichungszeitpunkt und der Ruf des Produkts ab.

Drei Ebenen des Testers im Großkonzern

Der Weg vom Anfänger zum Architekten von Testlösungen in einem großen Unternehmen ähnelt dem Durchlaufen von Leveln in einem komplexen RPG. Auf jeder Ebene gibt es eigene Monster und eigene Boni.

Ebene 1: Ausführender manueller Tests

Auf dieser Stufe schreibst du Checklisten und führst Regressionstests durch. Du bist die Augen des Teams. Deine Aufgabe ist es, Anomalien zu bemerken und einen Bug-Report korrekt zu formulieren.

Aber hier lauert eine Falle. Du kannst drei Jahre so arbeiten und auf derselben Ebene bleiben, indem du einfach mechanisch durch die Anwendung klickst. Dem Unternehmen ist das nützlich – du erledigst stetig deine Arbeit. Dir nicht.

💡 Rat: Wenn du dich länger als ein Jahr auf dieser Ebene befindest, fang sofort an, Automatisierung zu lernen. Nicht um komplexe Frameworks zu schreiben, sondern um deine eigene Routine zu automatisieren. Nimm eine beliebige sich wiederholende Überprüfung und schreibe ein Skript dafür in Python. Das wird deine Denkweise verändern.

Ebene 2: Automatisierungsingenieur

Hier suchst du Fehler nicht mehr manuell – du baust die Infrastruktur, die das für dich erledigt. Du schreibst Tests für APIs, richtest CI/CD ein, arbeitest mit Testumgebungen.

Der häufigste Fehler auf dieser Ebene ist der Versuch, alles zu automatisieren. „Wir haben 1000 manuelle Tests – lasst uns alle automatisieren!“ – das ist ein Weg ins Nichts. Automatisierung um der Automatisierung willen verschwendet Zeit und Ressourcen.

Ebene 3: Architekt von Testlösungen

Hier geht es nicht mehr ums Codieren, sondern um das Design des gesamten Testsystems. Du entscheidest, welche Tools verwendet werden, wie Testdaten organisiert werden, welche Metriken gesammelt werden, um die Produktqualität objektiv zu bewerten.

Ein Architekt hat nicht die Aufgabe, „einen Bug zu finden“. Seine Aufgabe ist es, sicherzustellen, dass Fehler nicht unbemerkt bleiben können. Er baut ein Qualitätssicherheitssystem.

Warum Kommunikation wichtiger ist als Code

Die häufigste Anfrage von HR-Verantwortlichen in Großkonzernen ist „Kandidat mit ausgeprägten Soft Skills“. Und das ist keine Laune. Im Enterprise arbeitest du nicht im luftleeren Raum.

Deinen Bug-Report lesen: der Entwickler (der möglicherweise in einer anderen Zeitzone ist), der Produktmanager (der technische Details nicht versteht), der Teamleiter (der die Release-Risiken bewertet).

Wenn du schreibst „Authentifizierung funktioniert nicht“ – wirst du nicht verstanden. Wenn du schreibst „Bei Eingabe einer ungültigen Telefonnummer unter iOS 17.2 stürzt die App mit dem Fehlercode EXC_BAD_ACCESS ab, dies geschieht nur auf einem echten iPhone 15 Pro Max“ – wirst du gehört, verstanden und es werden Maßnahmen ergriffen.

Das Geheimnis liegt darin, dass auch Entwickler ausgelastet sind. Sie haben ihr eigenes Backlog, ihre eigenen Aufgaben. Deine Aufgabe ist es, ihre Arbeit einfacher zu machen: fertige Informationen zu liefern, damit sie nicht überprüfen müssen.

Die Angst vor komplexer Infrastruktur und wie man sie überwindet

Wenn du zum ersten Mal die Architektur eines großen Produkts siehst – Dutzende Microservices, Nachrichtenwarteschlangen, mehrere in verschiedenen Regionen bereitgestellte Datenbanken, CI/CD-Pipelines mit Hunderten von Jobs – entsteht der natürliche Wunsch, den Laptop zuzuklappen und Taxifahrer zu werden.

Aber es gibt eine gute Nachricht: Niemand kennt dieses System vollständig.

Der Architekt, der dieses System geschrieben hat, kennt es zu 70 %. Das Entwicklungsteam zu 30 %. Du – der Tester – musst nicht alles wissen. Du musst wissen, wie du jede Information finden kannst.

💡 Rat: Erstelle deine persönliche „Spickzettel-Sammlung“. Lege in Notion oder Confluence eine Seite an, auf der du Folgendes sammelst: - Links zur Dokumentation für jeden Microservice; - Kontakte der Verantwortlichen für jedes Subsystem; - Interaktionsschemata; - typische Probleme und deren Lösungen. Dieses Dokument wächst mit dir und wird nach einem Jahr das wertvollste Artefakt im Unternehmen.

Kampf gegen Burnout: Warum Großkonzerne nichts für „Marathonläufer“ sind

Burnout entsteht nicht durch Überstunden, sondern durch die Sinnlosigkeit des Im-Kreis-Laufens.

Im Großkonzern tappt man leicht in die Falle: Du veröffentlichst Releases, schließt Tickets, nimmst an Meetings teil – und hast kein Gefühl von Fortschritt. Weil das Produkt groß ist und dein Beitrag in der Masse „untergeht“.

Die einzige Möglichkeit, dies zu vermeiden, ist, sich langfristige Projekte zu suchen, die du parallel zu den aktuellen Aufgaben verfolgst.

Wie man wächst: Ein konkreter Plan vom Tester zum Architekten

Angenommen, du bist jetzt ein manueller Tester mit 1–2 Jahren Erfahrung. Wohin soll es gehen?

Schritt 1: Lerne Python oder Java

Du musst kein Profi-Programmierer werden. Es reicht, um:

• Skripte zur Automatisierung von Routinen zu schreiben;
• fremden Code zu lesen;
• zu verstehen, wie Testframeworks funktionieren (pytest, JUnit).

Schritt 2: Beherrsche Request-Tools

Du musst sehen können, wohin die Anwendung geht. Charles, Fiddler, Postman – wähle eines und kenne es auf dem Niveau „Ich kann Requests abfangen, Antworten manipulieren, Header überprüfen“.

Schritt 3: Lerne mit Datenbanken zu arbeiten

SQL ist eine Superkraft. Wenn der Entwickler sagt „alles funktioniert“, schreibst du SELECT und siehst, dass der Datensatz nicht gespeichert wurde. Das beendet 80 % aller Diskussionen.

Schritt 4: Verstehe, wie CI/CD funktioniert

Jenkins, GitLab CI, GitHub Actions – jeder Tester mit mehr als 3 Jahren Erfahrung sollte eine einfache Pipeline zum Ausführen von Tests und Senden eines Berichts einrichten können.

Was tun, wenn du bereits im Großkonzern bist und das Gefühl hast, auf der Stelle zu treten

Das Schlimmste ist, in der Komfortzone zu bleiben, in der du jeden Button der getesteten Anwendung kennst, aber nicht wächst. Wie kannst du überprüfen, ob du dich weiterentwickelst?

Stelle dir drei Fragen:

1. Habe ich im letzten Monat etwas Neues darüber gelernt, wie das System funktioniert?
2. Habe ich aufgehört, Aufgaben manuell zu erledigen, die ich früher gemacht habe?
3. Hat mich jemand aus dem Team um Rat zum Testen gebeten?

Wenn auch nur eine Frage mit „nein“ beantwortet wird – befindest du dich in einer Stagnation.

💡 Rat: Der schnellste Weg aus der Stagnation ist, eine Aufgabe zu übernehmen, die niemand machen will. „Dieses Legacy-Modul wurde seit drei Jahren nicht getestet“, „Diese Tests fallen bei jedem Durchlauf – aber niemand hat sich darum gekümmert“, „Ein neues Feature kommt – es braucht Dokumentation.“ Nimm das an. Arbeite dich ein. Bringe es zu Ende. In drei Monaten wirst du der unersetzliche Experte für diesen Bereich.

Fazit: Der Großkonzern gibt mehr, als er nimmt

Die Arbeit in einem großen Unternehmen bedeutet nicht nur Bürokratie und lange Releases. Sie bedeutet Zugang zu enormem technischen Know-how, die Möglichkeit, mit skalierbaren Systemen zu arbeiten, und – am wichtigsten – Kollegen, die mehr wissen als du.

Deine Aufgabe ist es, keine Angst davor zu haben, Initiative zu ergreifen. Nicht zu warten, bis dir eine interessante Aufgabe gegeben wird. Gehe zum Architekten und frage: „Kann ich beim Testen des neuen Moduls helfen?“. Gehe zum DevOps und bitte um Zugriff auf Logs. Gehe zum Analysten und kläre Anforderungen.

Enterprise ist ein Ökosystem. Du kannst zehn Jahre darin unbemerkt arbeiten und dieselben manuellen Tests ausführen. Oder du kannst in zwei Jahren zu einem Spezialisten heranwachsen, der die Qualitätsstrategie des Produkts bestimmt.

Die Wahl liegt bei dir.