Day in the Life of a QA Engineer

Du willst wissen, was ein QA Engineer den ganzen Tag macht, und befürchtest, dass die Antwort "Tests schreiben" lautet. Die Wahrheit ist komplexer und anstrengender. Ich beschreibe hier einen realistischen Arbeitstag im mittleren Level, ohne Hochglanz.

Der Morgen: Mails, Slack und die erste Priorisierung#

Der Tag startet selten mit Code. Meistens startet er mit dem, was über Nacht passiert ist. Pipeline rot, ein Test sporadisch fehlgeschlagen, ein Kommentar von einem Entwickler in einem Bug-Ticket.

Ich schaue mir zuerst die CI-Ergebnisse an. War der Build grün, ist gut. War er rot, entscheide ich, ob ich das sofort fixe oder ob es ein echtes Problem im Produkt ist. Diese Unterscheidung frisst am Anfang viel Zeit und wird mit Erfahrung schneller.

Danach die Mails und Slack. Meistens drei Dinge: Rückfragen zu einem Bug, eine Terminänderung, jemand will wissen, ob ein Feature heute live gehen kann. Ich antworte kurz und verschiebe alles, was nicht brennt.

Der Vormittag: Meetings gegen Deep Work#

Der häufigste Fehler von neuen QA Engineers ist, Meetings einfach zu nehmen, wie sie kommen. In den meisten Teams bekommt man zwei bis vier Termine pro Tag, die den Vormittag zerschießen. Dazu kommen Stand-ups, Refinements, Sprint-Reviews, ad-hoc Calls, wenn etwas klemmt.

Ich blocke mir bewusst Zeit. Meine Regel: ein Block von mindestens 90 Minuten am Vormittag für konzentrierte Arbeit, keine Meetings. Das klappt nicht immer. Aber ich versuche es jeden Tag.

Ein typischer Vormittag sieht so aus: 15 Minuten Stand-up, 30 Minuten Testfälle für ein neues Ticket durchgehen, 60 Minuten für automatisierte Tests. Danach meistens schon wieder eine Unterbrechung.

Die Tools, die wirklich zum Einsatz kommen#

In der Stellenanzeige stehen oft zehn Tools. Im Alltag nutze ich vielleicht sechs regelmäßig. Die Liste ist ehrlicher als die meisten Jobprofile.

• Jira oder ein ähnliches Tool für Tickets, Bugs und Status
• Git und die Kommandozeile, für alles rund um Versionierung
• Eine CI-Pipeline wie GitHub Actions, GitLab CI oder Jenkins
• Ein Testmanagement-Tool oder eine einfache Tabellenkalkulation
• Postman oder curl für API-Tests
• Ein Browser mit DevTools, für alles was im Frontend schiefläuft
• Slack oder Teams, für den ständigen Austausch mit dem Team

Manche Teams nutzen Selenium, Cypress oder Playwright für automatisierte UI-Tests. Andere testen APIs fast ausschließlich. Das hängt stark vom Produkt ab. Ein Tool, das du beherrschen musst, ist die Kommandozeile. Ohne sie kommst du im Ernstfall nicht weiter.

Wenn du wissen willst, welche Tools in einer konkreten Stelle wirklich gebraucht werden, hilft es, die Ausschreibung genau zu lesen. Ein Job-Analyse-Tool wie der kostenlose JD Decoder zeigt dir, welche Begriffe dort wirklich vorkommen und welche nur Füllmaterial sind.

Der Nachmittag: Bug-Reports und Verhandlungen#

Der Nachmittag gehört oft den Bugs. Ich teste, finde etwas, und dann beginnt der Teil, den kaum jemand auf dem Schirm hat: die Kommunikation. Ein guter Bug-Report verhindert drei Rückfragen und spart allen Beteiligten eine Stunde.

So sieht ein schlechter Bug-Report aus: "Login funktioniert nicht."

So sieht ein guter aus: "Login schlägt fehl, wenn die E-Mail ein Pluszeichen enthält. Reproduziert in Chrome 124 auf macOS. Schritte: 1. Adresse mit [email protected] eingeben, 2. Passwort korrekt setzen, 3. Auf Anmelden klicken. Erwartet: Login erfolgreich. Tatsächlich: Fehlermeldung 'Ungültige E-Mail'. Siehe Screenshot und Netzwerk-Log im Anhang."

Der zweite Report nimmt mir keine fünf Minuten mehr. Aber er spart dem Entwickler eine halbe Stunde Rätselraten. Das ist der Teil des Jobs, der über Erfolg und Misserfolg entscheidet.

Der Nachmittag bringt auch Verhandlungen. Ein Entwickler sagt, das Verhalten sei kein Bug, sondern Feature. Der Product Owner will wissen, ob der Release gefahrlos raus kann. Ich habe selten eine eindeutige Antwort und muss trotzdem eine Empfehlung abgeben. Das ist unbequem und gehört dazu.

Die Druckpunkte, über die niemand spricht#

Release-Tage sind laut. Wenn etwas schiefläuft, ist die Frage "Warum hat QA das nicht gefunden?" nah. Man muss das aushalten können und sachlich antworten, ohne sich zu rechtfertigen.

Ein weiterer Druckpunkt: Testabdeckung versus Zeit. Du wirst nie alles testen können. Die Kunst ist, die Dinge zu finden, die dem Kunden wirklich wehtun, und den Rest zu dokumentieren. Perfektionismus ist hier kein Vorteil.

Dazu kommt die Langeweile. Regressionstests können monoton sein. Wenn du Abwechslung brauchst und keine findest, wird dich der Job unglücklich machen.

Was Neueinsteiger überrascht#

Der größte Schock für viele: Der Job ist zu vielleicht einem Drittel Technik. Der Rest ist Kommunikation, Priorisieren und Dokumentation. Wer denkt, er sitzt den ganzen Tag still am Code, wird enttäuscht.

Was viele ebenfalls nicht erwarten: Man muss oft Nein sagen. Nein zu einem Release, nein zu einem Test, der nicht mehr nötig ist, nein zu einem Termin. Das fällt am Anfang schwer.

Und: Du wirst selten der Held sein. Wenn alles gut läuft, merkt niemand die QA. Wenn etwas schiefgeht, fällt es sofort auf. Wer Anerkennung braucht, wird hier nicht glücklich.

Vom Junior zum Senior: Was sich ändert#

Als Junior teste ich vorgegebene Fälle und melde, was ich finde. Die Entscheidungen trifft jemand anderes. Das ist in Ordnung und der richtige Einstieg.

Im mittleren Level entscheide ich selbst, was getestet wird und wie tief. Ich schreibe Automatisierung, ich gestalte die Teststrategie für ein Feature, ich schule neue Leute im Team.

Als Senior geht es weniger ums Testen und mehr ums System. Ich setze Qualitätsstandards, ich beeinflusse, wie das Team entwickelt, ich spreche mit Management über Risiken. Der Anteil an Meetings steigt deutlich. Manche mögen das, andere gehen lieber in eine technische Spezialistenrolle.

Wenn du nach passenden Stellen suchst, findest du offene QA-Stellen in der Jobsuche. Und wer sich über den weiteren Karriereweg informieren will, findet im Karriere-Blog Erfahrungsberichte und praktische Tipps.

Ein realistischer Tagesplan#

• 08:30: CI-Ergebnisse checken, Mails und Slack sichten
• 09:00: Stand-up im Team
• 09:15: Testfälle für ein neues Feature durchgehen
• 10:30: Deep Work, automatisierte Tests schreiben oder pflegen
• 12:00: Mittagspause, wirklich weg vom Bildschirm
• 13:00: Review von Bug-Reports, Rückfragen klären
• 14:00: Exploratives Testen eines neuen Releases
• 15:30: Abstimmung mit Entwicklung oder Product
• 16:30: Dokumentation, Tickets aktualisieren, Tag abschließen

Der Plan ist selten zu 100 Prozent einzuhalten. Aber er zeigt, wie sich die Zeit tatsächlich verteilt. Wer mehr als vier Stunden konzentrierte Arbeit am Tag schafft, hat schon einen guten Tag.

Kostenlose Tools#

• jobrise.io/de/free-ats-checker/
• jobrise.io/de/free-jd-decoder/
• jobrise.io/de/jobs/
• jobrise.io/de/blog/

Häufige Fragen#

Wie viel eines QA-Engineer-Tages besteht wirklich aus Testen?

Im Erfahrungsbericht vieler Kollegen liegt der reine Testanteil zwischen einem Viertel und der Hälfte der Zeit. Der Rest geht für Meetings, Dokumentation, Bug-Triage und Abstimmung drauf. Wer fast nur testen will, sollte gezielt nach Teams mit hohem Automatisierungsanteil suchen.

Muss ich als QA Engineer programmieren können?

Für reine manuelle Tester-Stellen reicht es oft aus, Skripte lesen und kleine Änderungen machen zu können. Für den mittleren und gehobenen Bereich kommst du um Programmierkenntnisse nicht herum, meist JavaScript, Python oder Java. Ohne Automatisierung wirst du langfristig ausgebremst.

Wie hoch ist das Gehalt eines QA Engineers?

In Deutschland liegen die berichteten Spannen für mittlere Erfahrung grob zwischen 50.000 und 70.000 Euro brutto im Jahr, je nach Region, Branche und Tech-Stack. Die Zahlen variieren stark und sind nicht garantiert. Prüfe immer die aktuellen Angaben auf den offiziellen Seiten der Arbeitsagentur oder einschlägiger Gehaltsvergleiche.

Was ist der größte Unterschied zwischen Junior und Senior?

Ein Junior findet Bugs, ein Senior verhindert sie. Der Senior denkt in Risiken und Systemen, nicht in Testfällen, und verbringt deutlich mehr Zeit mit Kommunikation. Die technische Tiefe bleibt, aber der Fokus verschiebt sich.

Wie bereite ich mich auf ein QA-Interview vor?

Übe, einen Bug-Report live zu erklären, und bereite zwei, drei konkrete Beispiele vor, in denen du ein kritisches Problem gefunden hast. Zeige, wie du priorisierst, wenn die Zeit nicht reicht. Tools kannst du lernen, Urteilskraft musst du belegen.#