Wie man einen Lebenslauf für eine QA-Engineer-Position schreibt

Wonach ein Hiring Manager zuerst sucht

Wer einen QA-Engineer einstellt, liest den Lebenslauf beim ersten Durchgang nicht von oben nach unten. Er sucht nach drei Dingen, ungefähr in dieser Reihenfolge: was Sie getestet haben (die Domäne – Fintech, Healthcare, E-Commerce, Embedded, Games), wie Sie es getestet haben (manuell, automatisiert oder beides, und auf welcher Ebene – Unit, API, UI, End-to-End), und womit Sie es getestet haben (die spezifischen Tools aus ihrem Stack). Wenn diese drei Dinge nicht im ersten Drittel der Seite sichtbar sind, wird der Lebenslauf beiseitegelegt, weil der Leser einen Stapel davon hat und eine Stellenanzeige, die bestimmte Tools nicht ohne Grund genannt hat.

Deshalb ist „detailorientierter Teamplayer mit ausgeprägten Kommunikationsfähigkeiten" oben im QA-Lebenslauf verlorener Platz. Es sagt dem Leser nichts, was er nicht ohnehin annimmt, und es schiebt die nützlichen Informationen – Selenium, Playwright, Postman, was auch immer – weiter nach unten, wo sie beim Überfliegen übersehen werden könnten.

Setzen Sie Ihren Automation-Stack und Testing-Scope in die ersten Zeilen, entweder als kurze Zusammenfassung oder als Skills-Zeile direkt unter Ihrem Namen. Keine Skills-Wolke mit vierzig Tools in alphabetischer Reihenfolge – die Handvoll, die Sie tatsächlich in Production verwendet haben, mit genug Spezifität, dass jemand beim Lesen sofort weiß, ob Sie mit seinem Stack überlappen.

Qualifikationen und Zertifizierungen: was sie tatsächlich signalisieren

QA ist kein lizenzierter Beruf – es gibt kein Äquivalent zum Staatsexamen oder zur Krankenpflegeregistrierung. Niemand prüft ein Register, bevor Sie sich QA-Engineer nennen können. Das bedeutet, dass Zertifizierungen hier anders funktionieren als in regulierten Bereichen: Sie sind ein Signal für formale Grundlagen, keine gesetzliche Anforderung, und Hiring Manager gewichten sie sehr unterschiedlich.

Das ISTQB Foundation Level (und die höheren Advanced- und Expert-Levels, falls vorhanden) ist die Zertifizierung, die ein QA-Hiring-Manager am ehesten auf Anhieb erkennt, weil es das Nächste ist, was das Feld zu einem gemeinsamen Vokabular hat – Teststufen, Testarten, Defect-Life-Cycle, die in Testplänen verwendete Terminologie. Es verschafft Ihnen kein Interview allein, aber es wegzulassen, wenn Sie es haben, ist ein Fehler: Einige Applicant-Tracking-Systeme und einige Hiring Manager filtern danach.

Jenseits von ISTQB zählen eher tool-spezifische und cloud-spezifische Credentials, die direkt zur Stellenanzeige passen: AWS- oder Azure-Zertifizierungen, wenn die Rolle Cloud-Infrastruktur-Testing berührt, ein Certified Selenium Professional oder ähnliches, wenn Automation zentral ist, Security-Testing-Credentials wie OSCP oder CEH, wenn die Rolle eine Security-Testing-Komponente hat (zunehmend häufig in QA-Anzeigen, die nach penetration-nahen Skills fragen). Listen Sie diese nah am Namen oder in einer kurzen "Certifications"-Zeile auf, nicht ganz unten unter Bildung vergraben – ein Hiring Manager, der nach einer bestimmten, in der Stellenanzeige genannten Zertifizierung sucht, schaut zuerst oben.

Ein Informatik- oder Software-Engineering-Studium hilft, wird aber nicht als Hürde behandelt wie in manchen Engineering-Disziplinen – viele arbeitende QA-Engineers kamen aus anderen technischen oder sogar nicht-technischen Hintergründen, und Lebensläufe, die eine klare Testing-Laufbahn zeigen, wiegen tendenziell schwerer als ein fehlendes oder fachfremdes Studium. Wenn Ihr Studium nicht softwarebezogen ist, entschuldigen Sie sich nicht dafür oder erklären es weg – lassen Sie den Erfahrungsbereich sprechen.

Wie man Testing-Erfahrung belegt

Hier machen die meisten QA-Lebensläufe etwas falsch, und es ist immer derselbe Fehler: Verantwortlichkeiten auflisten statt Testing-Ergebnisse. "Verantwortlich für das Testen des Checkout-Moduls" sagt dem Leser nichts darüber, was Sie tatsächlich getan haben oder was sich dadurch geändert hat.

Was ein QA-Hiring-Manager für jede Rolle sehen will, ist eine Kombination aus:

• Was Sie getestet haben und auf welcher Ebene – Unit, Integration, API, UI, End-to-End, Performance, Security, Accessibility. Die Ebene zu nennen sagt dem Leser, wo Sie in der Testing-Pyramide stehen, was in diesem Feld eine echte Unterscheidung ist und beeinflusst, was eine Rolle tatsächlich braucht.
• Was Sie gefunden haben und was damit geschah. Nicht allein eine Defect-Anzahl (eine hohe Bug-Anzahl kann gründliches Testing oder ein schlecht gebautes Feature bedeuten – es liest sich nicht eindeutig positiv), sondern die Form der Arbeit: verwendete Severity-Klassifizierungen, wie Defects triagiert wurden, ob Sie die Reproduktionsschritte geschrieben haben, die einen Fix schneller zum Versand brachten.
• Was Sie automatisiert haben, und das Vorher-Nachher. "Regressionszyklus von drei Tagen manueller Ausführung auf eine zweistündige automatisierte Suite reduziert" ist konkret und in einem Interview überprüfbar, weshalb es genau deshalb besser ankommt als "Testing-Effizienz verbessert."
• Coverage, wo Sie sie ehrlich angeben können. Test-Coverage-Prozentsätze werden häufig in QA-Lebensläufen zitiert, aber sie sind ein Proxy für Gründlichkeit, kein Beweis dafür – ein Hiring Manager, der diesen Job gemacht hat, wird fragen, was das Coverage-Tool gemessen hat und ob es Line-, Branch- oder Requirement-Coverage war. Wenn Sie eine Zahl nennen, seien Sie bereit zu sagen, was sie gemessen hat.
• Ihre Position im Release-Prozess. Haben Sie das Sign-off für einen Release übernommen, oder Testfälle ausgeführt, die jemand anders geschrieben hat? Haben Sie den Testplan geschrieben oder einem gefolgt? Das ist eines der klarsten Signale für Seniorität in QA und es wird routinemäßig impliziert statt ausgesagt.

Schreiben Sie Testfälle und Bug-Reports so, wie Sie sie für ein echtes Ticket schreiben würden: spezifisch, reproduzierbar, mit dem Ergebnis angegeben. Ein Hiring Manager, der Tausende vage Bug-Tickets gelesen hat, wird einen CV-Bulletpoint bemerken, der wie einer liest.

Tools, Frameworks und Vokabular, die in diesen Lebenslauf gehören

Generisches "versiert mit Testing-Tools" ist unsichtbar. Nennen Sie den tatsächlichen Stack, weil die Tool-Namen echte Filterarbeit leisten, sowohl für einen Menschen, der die Seite überfliegt, als auch für jedes Keyword-Matching in einem Applicant-Tracking-System.

Automation-Frameworks und -Tools: Selenium, Playwright, Cypress, Appium (für Mobile), TestNG, JUnit, PyTest – und mit welcher Sprache Sie sie gepaart haben, da "Selenium" allein einem Leser nicht sagt, ob Sie es in Java, Python oder C# geschrieben haben.

API- und Service-Layer-Testing: Postman, REST Assured, SoapUI – nennen Sie diese getrennt von UI-Automation, weil API-Testing und UI-Testing verschiedene Skills sind und eine Stellenanzeige, die eines spezifiziert, Ihnen sagt, welches sie brauchen.

CI/CD und Pipeline-Integration: Jenkins, GitHub Actions, GitLab CI, CircleCI. Anzugeben, dass Ihre automatisierte Suite als Teil einer Pipeline lief, statt manuell getriggert zu werden, signalisiert eine reifere Testing-Praxis als ein eigenständiges, von Hand ausgeführtes Script.

Defect- und Test-Management: JIRA (und spezifisch, ob Sie Xray oder Zephyr daneben verwendet haben), TestRail, qTest. Diese sind es wert, genannt zu werden, weil verschiedene QA-Teams auf verschiedene standardisieren, und Vertrautheit mit dem spezifischen Tool in der Stellenanzeige entfernt Onboarding-Reibung, an die der Hiring Manager denkt.

Performance- und Load-Testing: JMeter, Gatling, k6 – eine separate Zeile wert, wenn Sie es haben, da es ein eigenständiges Skill-Set von funktionalem Testing ist und oft das, was einen Mid-Level-QA-Engineer von einem Senior unterscheidet.

Accessibility-Testing: axe, WAVE oder manuelles WCAG-Conformance-Testing – zunehmend gefragt und selten aufgelistet, was es wert macht, es einzuschließen, wenn Sie es wirklich getan haben.

Version-Control- und Environment-Vokabular: Git, Docker, Staging- versus Production-Environments, Feature-Flags. QA-Engineers, die darüber sprechen können, wie sie über Environments hinweg getestet haben, nicht nur was sie getestet haben, lesen sich als seniorig.

Was weggelassen wird und nicht sollte

Ein paar Dinge, die QA-Engineers routinemäßig auslassen, nicht aus Unehrlichkeit, sondern weil sie nicht daran denken, sie zu erwähnen:

Die Größenordnung dessen, was Sie getestet haben. Anzahl der gepflegten Testfälle, Größe der Regressionssuite, Anzahl der Environments oder Browser-/Device-Kombinationen abgedeckt. Diese Zahlen sind konkret und geben einem Hiring Manager ein Gefühl für die Betriebsgröße, ohne fragen zu müssen.

Ob Sie in einem Agile-Team gearbeitet haben und was Ihre Rolle im Sprint-Zyklus war – Acceptance-Criteria schreiben, innerhalb des Sprints versus danach testen, Teilnahme an Sprint-Planning oder Retrospectives. QAs Beteiligung an Agile-Zeremonien variiert stark zwischen Unternehmen und ist es wert, ausgesagt statt angenommen zu werden.

Teamübergreifende Arbeit mit Developers. Ob Sie mit Developers beim Test-Driven-Development gepairt haben, Pull Requests reviewt oder Tests geschrieben haben, die als Teil des Developer-eigenen Workflows liefen statt als separater QA-Pass. Diese Unterscheidung – QA als Gate am Ende versus QA eingebettet in Development – ist eine, nach der Hiring Manager aktiv screenen, und sie wird selten klar ausgesagt.

Jedes explorative Testing, das Sie gemacht haben, im Unterschied zur geskripteten Testfall-Ausführung. Es ist ein echter und geschätzter Skill in diesem Feld und zeigt sich nicht in einer automatisierten Test-Anzahl, also muss es direkt ausgesagt werden oder es ist unsichtbar.

Was als Nächstes zu tun ist

Legen Sie die Stellenanzeige neben Ihren Lebenslauf und prüfen Sie, dass die spezifischen Tools, Testing-Levels und Zertifizierungen, die sie nennt, auf Ihrem Lebenslauf in denselben Worten erscheinen, nah am Anfang. Schreiben Sie Ihre drei jüngsten Rollen als Testing-Ergebnisse um, nicht Verantwortlichkeiten – was Sie getestet haben, was Sie gefunden haben, was Sie automatisiert haben und was sich dadurch geändert hat. Streichen Sie den Zusammenfassungs-Absatz, der jeden Engineer beschreiben könnte, und ersetzen Sie ihn durch Ihren tatsächlichen Stack und Ihre Domäne.

Wenn Sie Lebensläufe schneller versenden, als Sie sie auf das anpassen können, was jede Anzeige spezifisch verlangt, kommt daher meist die Stille – nicht von der Qualität der Arbeit hinter dem Lebenslauf. jobmarket.pro liest jede Anzeige vollständig, gleicht sie gegen ein Profil ab, in das es keine Erfahrung hineinerfinden kann, und bereitet die Bewerbung daraus vor.