Das Portfolio eines Testers: Vom manuellen Testen zum Lösungsarchitekten

Wenn du in einem Startup anfängst, ist alles einfach. Du zeigst ein paar Projekte auf GitHub, erzählst, wie du Bugs gefunden hast, und wirst eingestellt. In einem Konzern sieht die Geschichte mit dem Portfolio anders aus. Dort schaut man nicht nur auf deine technischen Fähigkeiten, sondern auch auf deine Fähigkeit, mit großen, komplexen Systemen zu arbeiten, auf das Verständnis der Geschäftslogik und des Produktlebenszyklus. Eine einfache Liste von Projekten hilft hier nicht weiter.

Lass uns besprechen, wie du eine Mappe zusammenstellst, die dich nicht nur als Tester, sondern als wertvolles Mitglied eines großen Teams zeigt, und wie du den Weg vom manuellen Tester zum Architekten von Testlösungen gestaltest.

Warum „ich teste bloß“ nicht ausreicht

Stell dir eine Baustelle vor, auf der tausend Menschen arbeiten. Deine Aufgabe ist es zu prüfen, ob eine Wand im Neubau gerissen ist. Wenn du dem Vorarbeiter sagst: „Ich habe 25 Wände geprüft, alles in Ordnung“, sagt das nichts aus. Du musst zeigen: „Ich habe die tragenden Wände im zweiten Stock des Nordflügels geprüft und festgestellt, dass bei zwei die Bewehrung falsch eingelegt ist, was bei Belastung zu Rissen führen kann.“

Einem Corporate-Recruiter ist egal, wie viele Checklisten du abgearbeitet hast. Ihm ist wichtig zu verstehen:

• Wie du denkst.
• Wie du priorisierst, wenn es hunderte von Bugs gibt.
• Wie du mit Entwicklern kommunizierst, wenn du einen Fix noch vor dem morgigen Release unterbringen musst.

Was im Mittelpunkt stehen sollte

Du bist für ein Produkt verantwortlich, das täglich von Millionen Menschen genutzt wird. Das ist nicht nur „einen Bug finden“, sondern die Verantwortung dafür, dass jemand kein Geld verliert, kein Flug ausfällt oder das Essensliefer-System nicht zusammenbricht.

Dein Portfolio muss zeigen: „Ich verstehe diese Verantwortung. Ich sehe das System als Ganzes, nicht nur den Bereich meiner Checklisten.“

Vom manuellen Testen zur Automatisierung: Der entscheidende Schritt

Wenn du wachsen willst, wird dich das manuelle Testen ausbremsen. In einem Unternehmen mit Hunderten von Releases pro Jahr wirst du körperlich nicht in der Lage sein, dieselben Prüfungen immer wieder zu wiederholen. Du wirst zum Engpass.

Hier brauchst du Automatisierung. Aber Automatisierung in einem Konzern bedeutet nicht nur „einen Selenium-Test schreiben“. Es bedeutet:

• Integration in die CI/CD-Pipeline, sodass Tests bei jedem Commit laufen.
• Stabile Tests schreiben, die nicht jedes Mal aufgrund von zufälligem Flackern fehlschlagen.
• Mit verteilten Testumgebungen und Containern arbeiten können.

💡 Rat: Fang nicht mit riesigen Frameworks an. Nimm ein Projekt, mit dem du arbeitest, und automatisiere die langweiligste, sich wiederholendste Checkliste. Miss, wie viel Zeit du beim ersten Durchlauf gespart hast. Zeige diese Zahl in deinem Portfolio.

Was du in deine Mappe aufnehmen solltest

Deine Geschichte sollte ein System sein, keine Liste von Technologien. Zeige nicht, dass du Python kennst, sondern wie du ein Problem gelöst hast:

1. Problem: Jeder Release (und das waren 4 pro Tag) erforderte manuelle Regressionstests des Zahlungsmoduls. Dauerte 2 Stunden.
2. Lösung: Schrieb Autotests mit Python + Pytest, die in Jenkins nach jedem Build laufen.
3. Ergebnis: Reduzierte die Regressionszeit auf 10 Minuten. Fehler wurden innerhalb von 15-30 Minuten nach dem Commit gefunden, nicht erst am nächsten Tag.

Hier geht es nicht um Werkzeuge. Es geht um geschäftlichen Mehrwert.

Kommunikation im großen Team: Keine technische Fertigkeit, sondern eine Superkraft

Die komplexeste Infrastruktur in einem Konzern sind die Menschen. Wenn an einem Release 50 Entwickler, 5 Tester, 3 Analysten und ein Produktmanager beteiligt sind, entstehen Bugs oft nicht im Code, sondern an den Schnittstellen zwischen Systemen und durch Missverständnisse bei den Anforderungen.

Als Tester bist du die Brücke zwischen Business und Technik. Deine Aufgabe ist es nicht nur zu sagen „funktioniert nicht“, sondern zu sagen:

• „Wir haben einen Fehler, weil auf der API-Seite eine Änderung im Feld-Mapping nicht berücksichtigt wurde und das Frontend immer noch das alte Format erwartet. Die Teams müssen synchronisiert werden.“

Was in dein Anschreiben gehört

Zähle nicht die Technologien auf, die du kennst. Erzähle eine Geschichte über eine konkrete Krise, die du verhindert hast.

Das spricht für: vorausschauendes Denken, Proaktivität, Verständnis der Geschäftslogik, nicht nur technische Kompetenz.

Wie man im Enterprise nicht ausbrennt

Ein großes Unternehmen mit Hunderttausenden Zeilen Legacy-Code, Deadlines und politischen Spielchen kann jeden erschöpfen. Deine Aufgabe ist es nicht nur zu überleben, sondern zu wachsen.

Hier sind die größten Fallstricke und wie du sie umgehst:

• Angst vor Legacy-Code. Das ist kein Sumpf, sondern eine Schatzkarte. Je älter der Code, desto mehr versteckte „Teufel“ stecken darin. Wenn du ihn durchschaust und Tests automatisierst, wirst du unersetzlich.

• Das Problem „niemand schätzt mich“. Zeige Zahlen. Sammle Statistiken: „In diesem Quartal haben meine Tests 5 Vorfälle verhindert, die das Unternehmen N Stunden Support-Arbeit gekostet hätten“. Man liebt nicht Geschwätz, sondern messbaren Nutzen.

• Berufliches Burnout. Es kommt oft, wenn du monatelang dasselbe tust. Nimm dir unbedingt Zeit, um neue Werkzeuge zu lernen (selbst 2 Stunden pro Woche). Wenn du Fortschritt und Wachstum deiner Fähigkeiten siehst, weicht das Burnout.

💡 Rat: Erstelle in deinem Portfolio einen separaten Abschnitt „Architektur und Strategie“. Darin zeigst du, wie du ein fiktives, aber komplexes Produkt testen würdest – zum Beispiel ein Managementsystem für eine Fluggesellschaft. Das zeigt deine systemische Sichtweise.

Vom Tester zum Architekten: Der Wegweiser

In einem Konzern hast du drei Wachstumsstufen:

1. Spezialist. Du machst deine Arbeit qualitativ hochwertig. Du automatisierst, schreibst Testfälle, erledigst Aufgaben.
2. Experte. Man kommt zu dir um Rat. Du führst Code-Reviews für Autotests deiner Kollegen durch. Du beginnst darüber nachzudenken, wie du den Testprozess im Projekt selbst verbessern kannst.
3. Architekt. Du schreibst keine Tests mehr. Du entwirfst, wie sie im Unternehmen strukturiert sein sollen: Welche Frameworks verwendet werden, wie die Infrastruktur eingerichtet wird, wie verteilte Mikrodienste getestet werden.

Dein Portfolio sollte die Bewegung entlang dieses Weges zeigen. Bist du noch auf der ersten Stufe – Fokus auf Werkzeuge. Auf der zweiten Stufe – Fokus auf Lösungen für Teamprobleme. Auf der dritten Stufe – Fokus auf Konzepte und Strategien.

Was du jetzt in dein Portfolio aufnehmen solltest

Nimm eine einfache Textdatei oder eine Notion-Seite. Beginne, sie nach dieser Vorlage zu füllen:

• Titel: Position und Spezialisierung (QA Automation Engineer | Ziel: Wachstum zum QA Lead)

• Kernkompetenz: Ein Satz, der deinen Wert widerspiegelt (z. B.: „Baue Testprozesse unter Bedingungen schneller Releases auf“)

• Hervorstechender Fall: Eine Geschichte (nach dem Schema „Problem → Lösung → Ergebnis“), die maximal auf die Stelle passt, die du anstrebst.

• Basis: Eine kurze Liste von Technologien, bei der du nicht „kenne“, sondern „im Kontext einsetze“ zeigst (Java + Selenide + Jenkins, Docker, Rest Assured, Allure)

• Wachstumsvektor: „Ich lerne gerade Kubernetes, da ich die Automatisierung von Tests für Mikrodienst-Deployments plane.“

Keine 50 Textseiten. Gib dem Recruiter genau das, was er braucht, um in dir einen Experten zu sehen. Ein Blatt, das lauter spricht als eine Checkliste mit 1000 Punkten.