Vom Studenten zum Profi: Wie man im Corporate Testing überlebt und wächst

Stell dir vor, du hast dein ganzes Leben lang Schach mit deinem Banknachbarn gespielt. Du kennst seinen Stil, seine Schwächen, seine Lieblingseröffnungen. Und dann setzt man dich an einen Tisch mit einem Großmeister, der gleichzeitig auf zehn Brettern spielt, und jede seiner Figuren bewegt sich nach ihren eigenen Regeln.

Ungefähr so fühlt sich der Wechsel von der akademischen Welt (oder sogar von einem kleinen Produktunternehmen) ins Corporate Testing an.

Du bist an Vorhersehbarkeit gewöhnt. An klare Anforderungen. Daran, dass dein Code auf deinem lokalen Rechner abstürzt und du den Fehler sofort siehst.

In einem Unternehmen ist alles anders.

Hier kannst du einen Monat lang nach einem Bug suchen, der nur bei einer bestimmten Mondphase und einer spezifischen Version einer internen Bibliothek auftritt, die vor zehn Jahren von einem inzwischen ausgeschiedenen Entwickler geschrieben wurde. Hier kann dein automatisierter Test wochenlang laufen, weil die Infrastruktur ein komplexer Mechanismus mit vielen Zahnrädern ist.

Aber der Hauptunterschied liegt nicht einmal in der technischen Komplexität.

Er liegt darin, wie hier Entscheidungen getroffen werden.

Warum „einfach einen Bug finden“ nur der Anfang ist

In der akademischen Welt oder in einem Startup ist deine Arbeit klar: Du prüfst das Produkt, findest Fehler, erstellst Bug-Reports. Je mehr, desto besser. Du bist der Held, der die Benutzer vor Fehlern rettet.

In einem Unternehmen funktioniert diese Logik nicht immer.

Ein typischer Fehler von Neulingen ist, auf seiner Position zu beharren. „Wie kann das sein? Es gibt einen Bug! Der muss gefixt werden!“ Und dann die kalte Antwort zu bekommen: „Das haben wir bereits besprochen. Die Entscheidung ist gefallen.“

In einem Unternehmen ist Qualität keine absolute Größe. Sie ist ein Kompromiss zwischen Geschwindigkeit, Kosten und Risiko.

Deshalb ist deine Aufgabe nicht nur, einen Bug zu finden. Deine Aufgabe ist es, seine geschäftlichen Auswirkungen zu bewerten. Und argumentieren zu können, warum genau dieser Fehler jetzt behoben werden muss und nicht auf später verschoben werden kann.

💡 Rat: Wenn du einen Bug findest, frage dich: „Wen und wie wird das betreffen?“ Wenn es zu Geldverlusten, Reputationsschäden oder Gesetzesverstößen führt, ist dein Argument gewichtig. Wenn es ein „UI-Bug ist, den nur Admins einmal im Monat sehen“, kann er vielleicht aufgeschoben werden.

Infrastruktur: Wie man nicht im Legacy-Code versinkt

Kommen wir zu dem, was du wahrscheinlich nicht erwartest.

In einem Unternehmen arbeitest du selten mit einem „sauberen“ Produkt. Du arbeitest mit einem System, das über Jahre, wenn nicht Jahrzehnte, aufgebaut wurde.

Ein Teil des Codes ist in einer Sprache geschrieben, an die sich niemand mehr erinnert. Ein Teil der Tests sind Bash-Skripte, die einmal täglich per Cron gestartet werden. Die Dokumentation kann fehlen oder so veraltet sein, dass man ihr nicht trauen kann.

Und da bist du – der neue Test-Spezialist – und musst dich darin zurechtfinden.

Wie?

Erstens. Versuche nicht, alles sofort zu verstehen.

In einem Unternehmen ist die Informationsmenge über das System mit mehreren Bänden von „Krieg und Frieden“ vergleichbar. Wenn du anfängst, alles wahllos zu lesen, bist du in einem Monat ausgebrannt.

Die richtige Strategie ist „schichtweise“.

Verstehe zuerst, wie das System von außen aussieht: Was es tut, für wen, welche Hauptszenarien es gibt.

Dann, wie es logisch aufgebaut ist: Welche Dienste, wie sie interagieren, wo die Daten gespeichert sind.

Und erst dann die technischen Details: Wie CI/CD konfiguriert ist, wo die Tests liegen, welche Frameworks verwendet werden.

💡 Rat: Setze dir in der ersten Woche das Ziel: „Schreibe auf einer Seite eine Beschreibung des Systems, die ein Fünftklässler versteht.“ Wenn du das kannst, hast du das Wesentliche verstanden. Wenn nicht, gräbst du dich in Details, die noch nicht nötig sind.

Kommunikation: Wie man nicht „der typische Tester“ wird

Die häufigste Beschwerde in Unternehmen ist: „Tester bremsen Releases aus.“

Nicht „sie finden Bugs“. Nicht „sie verbessern die Qualität“. Sie bremsen aus.

Und das ist nicht immer fair, aber es ist die Realität.

Warum passiert das?

Weil in einem großen Team nicht nur deine technische Expertise zählt, sondern auch, wie du sie präsentierst.

Wenn du in den Chat schreibst: „Build ist gefallen, alles schlecht, fixen“ – wirst du nicht verstanden. Der Entwickler hat vielleicht seine eigenen Aufgaben, seine eigene Deadline, seinen eigenen Kontext.

Vom manuellen Testen zur Architektur: Eine Wachstumskarte

Kommen wir zu dem, warum du überhaupt hier bist – zur Karriere.

In einem Unternehmen sieht der klassische Weg eines QA-Ingenieurs so aus:

1. Junior / Manueller QA – Du testest manuell, schreibst Checklisten, erstellst Bugs.
2. Middle QA / Automation QA – Du automatisierst Regressionen, schreibst Test-Frameworks, richtest CI ein.
3. Senior QA / QA Lead – Du entwirfst die Teststrategie, leitest ein Team, bist für die Qualität auf Produktebene verantwortlich.
4. QA Architect / Test Architect – Du baust die Testinfrastruktur auf, wählst Werkzeuge aus, definierst Standards.

Aber es gibt einen Haken.

Der Übergang zwischen diesen Ebenen ist nicht einfach „lerne ein neues Tool“. Es ist ein Wandel der Denkweise.

💡 Rat: Um von manuellem Testen zur Automatisierung zu gelangen, reicht es nicht, Selenium zu lernen. Du musst anfangen, wie ein Entwickler zu denken: über Code-Modularität, Fehlerbehandlung, Test-Performance.

Um vom Senior zum Architect aufzusteigen, reicht es nicht, gute Tests zu schreiben. Du musst die Geschäftsstrategie verstehen: Warum habt ihr genau diese Architektur gewählt, wie viel kostet eine Minute CI-Ausfallzeit, wie beeinflusst die Qualität die Benutzerbindung?

Wenn du wachsen willst – schau nicht nur auf den Code, sondern auch nach oben.

Die Burnout-Falle: Wie man sich nicht verliert

Ein Unternehmen dreht sich um Tempo.

Releases alle zwei Wochen. Meetings jeden Tag. Tausende Nachrichten in Chats. Ein ständiger Informationsfluss.

Und wenn du dir keine Grenzen setzt, bist du in einem halben Jahr ausgebrannt.

Die Anzeichen eines Burnouts sind für Tester spezifisch:

– Du hörst auf zu glauben, dass man jeden Bug finden kann. „Wir werden sowieso etwas übersehen.“ – Du beginnst, das Wort „Regression“ zu hassen. – Du testest nur noch den „Positiv-Pfad“, weil du für „negative“ Szenarien keine Kraft mehr hast. – Du hörst auf, mit Entwicklern zu diskutieren, selbst wenn du im Recht bist.

💡 Rat: In einem Unternehmen tappt man leicht in die „Helden-Falle“. Wenn du alles auf dich nimmst, wirst du zunächst gelobt und dann mit Arbeit überhäuft. Lerne, „Nein“ zu sagen und zu argumentieren, warum. Nicht „das werde ich nicht tun“, sondern „ich schaffe das nicht rechtzeitig in der erforderlichen Qualität, lasst uns die Prioritäten überdenken“.

Angst vor komplexer Infrastruktur

Eine weitere Falle ist die Angst.

Du siehst dir eine Microservice-Architektur mit 50 Diensten, eine verteilte Datenbank, ein CI/CD mit unzähligen Jobs an – und dir scheint, als würdest du das nie verstehen.

Kommt dir bekannt vor?

Hier ist das Geheimnis: Niemand versteht alles vollständig.

Selbst der Architect, der dieses System entworfen hat, kennt nicht alle Implementierungsdetails jedes Moduls. Er kennt die Prinzipien, die Verbindungen, die Logik.

Deine Aufgabe ist nicht, alle 50 Dienste zu lernen. Deine Aufgabe ist zu verstehen, wie man das testet, was in deinem Verantwortungsbereich liegt.

Was du jetzt tun kannst: Ein Aktionsplan

Wenn du diesen Artikel liest und denkst: „Ich will ins Unternehmen“ – hier sind konkrete Schritte.

1. Studiere die Qualitätskultur des Zielunternehmens. Geh auf ihre Karriereseite, lies die Ingenieur-Blogs. Verstehe, wie bei ihnen getestet wird: manuell vs. automatisiert, was sie als kritisch ansehen.

2. Bau deine Automatisierungskenntnisse aus. Selbst wenn du dich auf eine manuelle Position bewirbst – die Kenntnis grundlegender Frameworks (Selenium, Rest Assured, JUnit) verschafft dir einen Vorteil. In Unternehmen wechselt man schnell vom manuellen Testen zur Automatisierung.

3. Lerne, fremden Code zu lesen. Nicht deinen eigenen, sondern den von anderen. Du wirst mit Legacy arbeiten. Die Fähigkeit, sich schnell in fremdem Code zurechtzufinden, ist eine Superkraft.

4. Verbessere deine Fähigkeit zur „freundlichen Ablehnung“. Lerne, argumentativ „Nein“ oder „Lass es uns anders machen“ zu sagen. Das bewahrt dich vor unrealistischen Deadlines.

5. Finde einen Mentor. In Unternehmen gibt es normalerweise ein Mentoring-Programm. Wenn nicht, suche einen erfahreneren Kollegen, dem du „dumme“ Fragen stellen kannst. Habe keine Hemmungen.

Die wichtigste Erkenntnis

Der Wechsel von der akademischen Welt ins Unternehmen bedeutet nicht nur einen Werkzeugwechsel. Es ist ein Wandel der Denkweise.

Du hörst auf, ein „Einzelkämpfer zu sein, der Bugs sucht“. Du wirst Teil eines Systems, in dem Qualität ein Kompromiss ist, Kommunikation eine Fähigkeit und Karriere eine Leiter mit mehreren Stufen.

Lerne, nicht nur den Code zu sehen, sondern auch das Geschäft. Lerne, nicht nur Anforderungen zu hören, sondern auch den Kontext. Lerne, Qualität zu verteidigen, ohne „derjenige zu werden, der Releases aufhält“.

Und denk daran: In einem Unternehmen schätzt man nicht denjenigen, der die meisten Bugs findet, sondern den, der dem Team hilft, das Produkt schneller und zuverlässiger auszuliefern.

Werde ein solcher Spezialist – und du wirst dich nicht nur anpassen. Du wirst wachsen.