Was wird im Vorstellungsgespräch als Softwaretester am häufigsten gefragt?

Wie du entscheidest, was du testest (Strategie, Risiko, Testentwurf), wie du automatisierst (Frameworks, instabile Tests, APIs, CI) und wie du mit Fehlern umgehst. Bei Testlead und Testmanager kommen Planung, Kennzahlen und Menschen dazu.

Gibt es für Softwaretester eine Programmieraufgabe?

Oft, bei Rollen in der Automatisierung und als SDET: eine kleine Übung in der Sprache des Teams, etwa einen Test für eine API schreiben oder einen instabilen Test reparieren. Bei Rollen für manuelles Testen gibt es meist stattdessen Übungen zum Testentwurf.

Welches Framework sollte ich zuerst lernen?

Ein modernes Browser-Werkzeug, Playwright oder Cypress, dazu API-Tests in der Sprache, die du am besten kannst. Die Ideen lassen sich auf Selenium und andere übertragen.

Brauche ich das ISTQB-Zertifikat für das Vorstellungsgespräch?

Nicht, um gut zu antworten, aber seine Begriffe (Äquivalenzklassen, Grenzwerte, Schweregrad und Priorität) sind nützlich, und viele Anzeigen in Europa nennen das Zertifikat.

Wie bereite ich mich in einer Woche vor?

Sag die kurzen Antworten laut, bereite zu jedem Abschnitt eine echte Geschichte vor und übe, Tests für ein einfaches Formular oder eine API zu entwerfen und dabei deine Entscheidungen zu erklären.

Interviewfragen für Softwaretester, mit ausgearbeiteten Antworten

Siebzehn Fragen, die in Vorstellungsgesprächen für Softwaretester immer wieder kommen, vom ersten Job bis zum Testmanager. Zu jeder: worauf der Interviewer achtet, eine kurze Antwort, die ausführliche Antwort in einfachen Worten, eine schwache Antwort, die du vermeiden solltest, und eine typische Nachfrage.

Das cvscored-TeamVeröffentlicht 05.11.2026 · Aktualisiert 05.11.2026

Inhalt

So nutzt du diese Fragen
Was ein Softwaretester können muss
Teststrategie und Testentwurf
Testautomatisierung und Frameworks
Tests in der Pipeline
Fehler und Fehlermanagement
Testplanung, Kennzahlen und Teamführung
Dein Lebenslauf für diese Fragen
Das Wichtigste
Häufige Fragen
Mehr zu diesem Beruf

So nutzt du diese Fragen

Lies die kurze Antwort und sag sie laut. Das sind deine ersten dreißig Sekunden. Lies dann die ausführliche Antwort und such dir zwei oder drei Punkte aus, die du ergänzt, mit einem Beispiel aus deiner eigenen Arbeit. Interviewer wollen hören, wie du entscheidest, was du testest, was du weglässt und woran du erkennst, dass es funktioniert hat.

Was ein Softwaretester können muss

Testentwurf: aus einer Funktion die wenigen Tests machen, die zählen, mit Techniken wie Grenzwerten (Tests an den Rändern dessen, was erlaubt ist) und explorativem Testen (das Produkt kennenlernen, während du es testest).
Testautomatisierung: Prüfungen, die eine Maschine bei jeder Änderung ausführt, so geschrieben, dass das Team ihnen vertraut.
Ein Browser-Werkzeug: Selenium, Cypress oder Playwright, und wann du den Browser gar nicht brauchst.
Eine Sprache: Python, Java, JavaScript oder TypeScript, auf dem Niveau von sauberem, reviewtem Testcode.
APIs und Daten: REST-APIs direkt testen, und SQL, um zu prüfen, was ein Test hinterlassen hat.
Die Pipeline: CI/CD (die Schritte, die jede Änderung bauen, testen und ausliefern), Git und Docker für saubere Testumgebungen.
Wie das Team arbeitet: Agile Methoden und Scrum, Akzeptanzkriterien und TDD (den Test vor dem Code schreiben) gemeinsam mit Entwicklern.
Fehler: klare Berichte in einem Werkzeug wie Jira, und wie ein Fehler von „gefunden“ über „behoben“ zu „geprüft“ kommt.

Teststrategie und Testentwurf

Wie würdest du eine Teststrategie für ein neues Produkt oder eine große neue Funktion aufbauen?

Worauf sie achten: dass du beim Risiko und bei den Nutzern des Produkts anfängst, nicht bei einer Vorlage; dass du Teststufen mischst; und dass du sagst, woran du erkennst, dass das Testen fertig ist.

Kurze Antwort: „Zuerst finde ich heraus, was das Produkt nie falsch machen darf und wer es nutzt. Ich liste die Risiken auf und ordne sie danach, wie wahrscheinlich und wie schlimm sie wären. Dann lege ich fest, was jede Teststufe abdeckt: viele schnelle Unit- und API-Prüfungen, weniger End-to-End-Tests für die wichtigsten Abläufe und exploratives Testen für die neuen und riskanten Teile. Mit dem Team vereinbare ich, was ‚fertig‘ heißt, bringe die Prüfungen in die Pipeline und berichte das Risiko in einfachen Worten.“

Die ausführliche Antwort in sieben Schritten:

Das Produkt verstehen. Wer nutzt es, was muss es tun, was darf es nie tun (Geld verlieren, Daten preisgeben, Menschen aussperren), mit welchen Systemen spricht es, und was verlangen Gesetz oder Branche?
Die Risiken auflisten und ordnen. Frag für jeden Teil, wie wahrscheinlich ein Fehler ist und wie schlimm er wäre. Zahlung, Anmeldung und personenbezogene Daten stehen meist vorn. Diese Rangfolge ist das Herz der Strategie.
Die Teststufen festlegen. Unit-Tests (kleine Prüfungen der Entwickler für ein einzelnes Stück Code), API-Tests, wenige End-to-End-Tests über die Oberfläche und explorative Sessions. Sag, welche Risiken jede Stufe abdeckt, damit nicht dasselbe dreimal getestet wird.
Festlegen, was nicht getestet wird, und warum. Erst wenn das aufgeschrieben ist, wird daraus eine Strategie statt einer Wunschliste. Stabile Teile mit geringem Risiko bekommen leichte Prüfungen.
Umgebungen und Testdaten planen. Wo die Tests laufen, wie Daten angelegt und wieder aufgeräumt werden und wie personenbezogene Daten aus den Testsystemen herausbleiben.
In die Pipeline bringen. Schnelle Prüfungen bei jeder Änderung, die längere Suite jede Nacht oder vor einem Release, und eine klare Regel, was ein Release stoppt.
Vereinbaren, wie du berichtest. Welche Risiken abgedeckt sind, welche offen, und was du empfiehlst. Prüf die Strategie neu, wenn sich das Produkt oder die Risiken ändern.

Schwache Antwort: „Ich schreibe Testfälle für jede Anforderung und automatisiere sie.“ Keine Rangfolge der Risiken, keine Stufen, nichts bewusst weggelassen.

Nachfrage: „Du hast nur die Hälfte der geplanten Zeit. Was ändert sich?“ Die höchsten Risiken bleiben voll abgedeckt, bei den niedrigen wird weniger tief getestet, und du sagst dem Team schriftlich, welche Risiken jetzt offen sind.

Was ist die Testpyramide, und hältst du dich immer an sie?

Worauf sie achten: dass du weißt, warum es die Pyramide gibt, und dass du sie anpassen kannst.

Kurze Antwort: „Die Testpyramide sagt: unten viele kleine, schnelle Unit-Tests, in der Mitte weniger API- oder Integrationstests und oben nur wenige langsame End-to-End-Tests. Schnelle Tests geben rasch Rückmeldung und brechen seltener. Ich folge der Idee, nicht der genauen Form: Wichtig ist, dass jedes Risiko auf der günstigsten Stufe getestet wird, die es erkennen kann.“

Die ausführliche Antwort: UI-Tests sind langsam und brechen, wenn ein Button verschoben wird; eine Suite, die vor allem aus ihnen besteht (man nennt das Eistüte), wird langsam und instabil. Manche Produkte brauchen aber eine andere Form. Ein Frontend mit wenig Logik braucht vielleicht mehr Komponententests. Ein System, das viele Services verbindet, braucht mehr Contract-Tests (Prüfungen, ob sich zwei Services über das Format ihrer Nachrichten einig sind). Ich schaue, woher die Fehler tatsächlich kommen, und schiebe Tests eine Stufe nach unten, wann immer es geht.

Schwache Antwort: „Wir automatisieren alles über die Oberfläche, dann ist es wie ein echter Nutzer.“ Nachfrage: „Deine End-to-End-Suite läuft zwei Stunden. Was tust du?“ Die Prüfungen finden, die keinen Browser brauchen, und sie in API-Tests verlegen, den Rest parallel laufen lassen und nur die wichtigsten Abläufe End-to-End behalten.

Was ist risikobasiertes Testen, und wie machst du es im Sprint?

Worauf sie achten: dass du schnell entscheiden kannst, was am wichtigsten ist, und es erklären kannst.

Kurze Antwort: „Risikobasiertes Testen heißt, die Testzeit dort einzusetzen, wo ein Fehler am wahrscheinlichsten ist und am meisten schaden würde. Im Refinement frage ich, was kaputtgehen kann und was es kosten würde, bewerte jede Story und teste die riskanten gründlich und die harmlosen leicht.“

Die ausführliche Antwort: Ich nutze zwei einfache Skalen, wie wahrscheinlich und wie schlimm, und multipliziere sie. Zeichen für hohe Wahrscheinlichkeit: neuer Code, komplexe Regeln, viele Änderungen, ein Teil mit vielen Fehlern in der Vergangenheit. Zeichen für hohe Auswirkung: Geld, personenbezogene Daten, das Gesetz, viele Nutzer. Riskante Stories bekommen einen Testentwurf, bevor der Code geschrieben ist, automatisierte Prüfungen und eine explorative Session. Harmlose bekommen eine kurze Prüfung. Ich schreibe die Bewertungen dorthin, wo das Team sie sieht, damit die Entscheidung geteilt ist und nicht versteckt.

Schwache Antwort: „Jede Story wird gleich getestet, sicherheitshalber.“ Nachfrage: „Der Product Owner hält eine Story für harmlos, du nicht.“ Zeig die Belege (frühere Fehler, die Daten, die sie berührt), einigt euch gemeinsam auf eine Bewertung und halte die Entscheidung fest.

Wie würdest du ein Registrierungsformular mit E-Mail, Passwort und Geburtsdatum testen?

Worauf sie achten: echte Techniken des Testentwurfs, keine zufällige Liste von Ideen.

Kurze Antwort: „Ich teile jedes Feld in Gruppen von Werten, die sich gleich verhalten sollten, teste einen Wert aus jeder Gruppe und die Ränder dazwischen. Dann teste ich die Felder zusammen, die Fehlermeldungen, Sicherheit, Barrierefreiheit und was danach mit den Daten passiert.“

Die ausführliche Antwort: Beim Geburtsdatum sind die Gruppen: zu jung, alt genug, unmögliche Daten und leer; die Ränder sind der Tag, an dem jemand alt genug wird, und der Tag davor. Das sind Äquivalenzklassen (Gruppen, die sich gleich verhalten) und Grenzwertanalyse (Tests an den Rändern). Bei der E-Mail: gültig, ungültig, schon vergeben, sehr lang, mit Großbuchstaben. Beim Passwort: jede Regel knapp erfüllt und knapp verfehlt. Dann das ganze Formular: Kann sich dieselbe E-Mail zweimal registrieren, wenn zwei Leute gleichzeitig klicken? Wird das Passwort nie angezeigt oder geloggt? Lässt es sich mit Tastatur und Screenreader bedienen? Kommt die Bestätigungsmail an, und wird das Konto nur einmal angelegt?

Schwache Antwort: „Ich würde ein paar gültige und ungültige Werte ausprobieren.“ Nachfrage: „Was davon würdest du automatisieren?“ Die Feldregeln auf API-Ebene, eine Registrierung End-to-End und den Fall mit der doppelten E-Mail; Barrierefreiheit und seltsame Eingaben als explorative Sessions.

Wann setzt du exploratives Testen ein, und wie wird daraus mehr als Herumklicken?

Worauf sie achten: dass du menschliches Testen schätzt und es mit Struktur durchführen kannst.

Kurze Antwort: „Ich nutze es für neue Funktionen, riskante Änderungen und alles, was Automatisierung nicht beurteilen kann, etwa ob ein Ablauf Sinn ergibt. Ich mache es in kurzen Sessions mit einer Charter, einem klaren Ziel für die Session, mache Notizen und berichte, was ich abgedeckt und was ich gefunden habe.“

Die ausführliche Antwort: Eine Charter sagt, was erkundet wird, womit und um was zu finden, zum Beispiel „den Erstattungsablauf mit Teilerstattungen erkunden, um falsche Summen zu finden“. Eine Session dauert sechzig bis neunzig Minuten. Ich notiere die Wege, die ich ausprobiert habe, die Fragen, die dabei aufkamen, und die Fehler. Danach wird jede Prüfung, die sich zu wiederholen lohnt, ein automatisierter Test. So helfen sich Exploration und Automatisierung gegenseitig.

Schwache Antwort: „Exploratives Testen ist, wenn keine Zeit für Testfälle bleibt.“ Nachfrage: „Wie zeigst du einer Führungskraft, was eine Session abgedeckt hat?“ Mit der Charter, den Notizen und einer kurzen Zusammenfassung der abgedeckten Bereiche, offenen Fragen und Fehler.

Testautomatisierung und Frameworks

Wie würdest du ein Framework für die Testautomatisierung eines Webprodukts auswählen?

Worauf sie achten: dass du nach dem Bedarf des Teams wählst, nicht aus Gewohnheit, und daran denkst, wer die Tests am Laufen hält.

Kurze Antwort: „Ich schaue auf das Produkt, die Sprache des Teams und das, was getestet werden muss. Für eine moderne Web-App würde ich meist Playwright oder Cypress ausprobieren, weil sie von selbst auf die Seite warten und sich schnell debuggen lassen. Selenium passt, wenn wir viele Browser brauchen oder die Firma schon Java nutzt. Bevor ich entscheide, probiere ich den Favoriten an zwei oder drei echten Abläufen aus.“

Die ausführliche Antwort: Ein Framework heißt hier das Werkzeug plus die Struktur drumherum: wie Tests organisiert sind, wie sie an Daten kommen, wie sie berichten. Meine Fragen: In welcher Sprache schreibt das Team? Tests in der Sprache der Entwickler werden auch von Entwicklern reviewt und repariert. Welche Browser und Geräte müssen wir abdecken? Läuft es in unserer Pipeline und parallel? Wie gut sind Berichte, Screenshots und Traces, wenn ein Test fehlschlägt? Wird es gut gepflegt? Dann ein kurzer Versuch: dieselben paar Tests schreiben, zwanzigmal laufen lassen und Geschwindigkeit, Stabilität und Verständlichkeit der Fehler vergleichen. Die Entscheidung schreibe ich mit den Gründen auf.

Schwache Antwort: „Selenium, weil das der Standard ist.“ Nachfrage: „Wie hältst du die Tests leicht änderbar?“ Page Objects oder Ähnliches (eine Stelle, die jeden Bildschirm kennt), Testdaten im Code erzeugt, keine festen Wartezeiten, und Testcode, der wie Produktcode reviewt wird.

Deine automatisierten Tests schlagen zufällig fehl. Wie gehst du mit instabilen Tests um?

Worauf sie achten: dass du instabile Tests als echtes Problem behandelst und Ursachen behebst, nicht Symptome.

Kurze Antwort: „Ein instabiler, ‚flaky‘ Test läuft mal grün, mal rot, ohne dass sich der Code ändert, und dann vertraut niemand mehr der Suite. Ich messe, welche Tests flaky sind, nehme sie aus dem blockierenden Lauf, bis sie repariert sind, und behebe die Ursache: meist das Warten, geteilte Testdaten oder ein Test, der von einem anderen abhängt.“

Die ausführliche Antwort: Zuerst messen: die Suite viele Male laufen lassen oder die Historie der Pipeline lesen und die Tests auflisten, deren Ergebnis wechselt. Dann die Ursachen sortieren. Timing: Der Test handelt, bevor die Seite bereit ist, also auf ein klares Signal warten statt auf eine feste Pause. Daten: Zwei Tests nutzen denselben Datensatz, also bekommt jeder Test eigene Daten. Reihenfolge: Ein Test braucht einen anderen vorher, also legt jeder Test selbst an, was er braucht. Umgebung: ein langsames oder geteiltes Testsystem, also Container nutzen oder den fremden Service durch einen Stub ersetzen. Manchmal ist die Instabilität ein echter Fehler im Produkt, etwa ein Wettlauf zwischen zwei Anfragen; schau also hin, bevor du dem Test die Schuld gibst. Verfolge die Flaky-Rate über die Zeit und mach sie sichtbar.

Schwache Antwort: „Fehlgeschlagene Tests laufen bei uns automatisch dreimal.“ Das versteckt echte Fehler und bringt dem Team bei, Rot zu ignorieren. Nachfrage: „Eine Führungskraft will alle instabilen Tests löschen.“ Lösch nur die, deren Risiko anderswo abgedeckt ist; den Rest in Quarantäne nehmen und reparieren, mit einer verantwortlichen Person und einem Termin.

Was automatisierst du, und was testest du weiter von Hand?

Worauf sie achten: Urteilsvermögen bei Kosten und Nutzen.

Kurze Antwort: „Ich automatisiere Prüfungen, die oft wiederholt werden, stabil sind und etwas Wichtiges schützen: Regressionsprüfungen, API-Regeln, die wichtigsten Abläufe der Nutzer. Menschliches Testen behalte ich für neue Funktionen, Benutzbarkeit und alles, was Urteil braucht oder sich jede Woche ändert.“

Die ausführliche Antwort: Bei jedem Kandidaten frage ich: Wie oft läuft das, was kostet ein Fehler hier, wie stabil ist die Funktion, und wie schwer ist die Prüfung zu schreiben und zu pflegen? Eine Prüfung, die bei jeder Änderung läuft und Zahlungen schützt, ist viel wert. Eine Prüfung für einen Bildschirm, der jeden Monat neu gestaltet wird, noch nicht. Barrierefreiheit ist halb und halb: Werkzeuge finden einige Probleme, ein Mensch mit Screenreader findet den Rest.

Schwache Antwort: „Wir streben hundert Prozent Automatisierung an.“ Nachfrage: „Woran erkennst du, dass sich deine Automatisierung lohnt?“ An den Fehlern, die sie vor dem Release gefunden hat, an der gesparten Zeit bei Regressionstests und daran, wie oft das Team auf ihre Ergebnisse reagiert.

Wie testest du eine REST-API?

Worauf sie achten: dass du über den Gutfall hinaus testest, auch Sicherheit und Daten.

Kurze Antwort: „Ich prüfe jeden Endpunkt gegen seinen Vertrag: die richtigen Statuscodes, die Felder und ihre Typen und klare Fehler bei falscher Eingabe. Dann die Regeln dahinter: wer ihn aufrufen darf, was er an den Daten ändert und wie er sich unter Last verhält oder wenn eine Abhängigkeit ausfällt.“

Die ausführliche Antwort: Eine REST-API ist die Menge von Adressen, die ein Programm aufruft, um Daten zu lesen oder zu ändern. Ich teste: gültige Anfragen; fehlende, falsche oder zusätzliche Felder; sehr große Eingaben; Aufrufe ohne Login und mit dem Login eines anderen (kann Nutzer A die Bestellung von Nutzer B lesen?); dieselbe Anfrage zweimal gesendet; und was danach in der Datenbank steht, geprüft mit SQL. Contract-Tests fangen einen geänderten Feldnamen ab, bevor die App eines anderen Teams bricht. Diese Prüfungen sind schnell und deshalb die wichtigste Schicht meiner Automatisierung, geschrieben in der Sprache des Teams, zum Beispiel Python oder Java.

Schwache Antwort: „Ich schicke Anfragen in Postman und prüfe, dass 200 zurückkommt.“ Nachfrage: „Die API ruft einen Zahlungsdienstleister auf. Wie testest du das?“ Mit einem Stub (einer Attrappe, die wie der Dienstleister antwortet) für die meisten Tests, auch für seine Fehlerfälle, und ein paar Prüfungen gegen das Testsystem des Dienstleisters.

Tests in der Pipeline

Wie bringst du Tests in eine CI/CD-Pipeline?

Worauf sie achten: dass du auf schnelle Rückmeldung hin planst und eine klare Regel hast, wann ein Release gestoppt wird.

Kurze Antwort: „CI heißt, jede Änderung wird automatisch gebaut und getestet. Die schnellen Prüfungen, Unit und API, laufen bei jeder Änderung, damit ein Entwickler es in wenigen Minuten weiß. Längere End-to-End-Tests laufen parallel vor dem Merge oder jede Nacht. Eine fehlgeschlagene Prüfung stoppt die Änderung, und der Bericht sagt klar, was fehlgeschlagen ist und warum.“

Die ausführliche Antwort: Ich lege Stufen fest: Build, Unit-Tests, API- und Contract-Tests, dann das Deployment in eine Testumgebung und die End-to-End-Prüfungen für die wichtigsten Abläufe. Jede Stufe hat ein Zeitbudget, zum Beispiel die erste Rückmeldung innerhalb von zehn Minuten. Tests laufen parallel, in sauberen Containern mit Docker. Berichte enthalten Screenshots und Logs zu Fehlern. Nach einem Release laufen ein paar Smoke-Tests (kurze Prüfungen, ob das Wichtigste funktioniert) gegen die Produktion. Das Pipeline-Werkzeug kann Jenkins, GitLab CI oder GitHub Actions sein; der Aufbau ist derselbe.

Schwache Antwort: „Das QA-Team lässt vor jedem Release die Regressionssuite laufen.“ Nachfrage: „Die Pipeline ist fast jeden Morgen rot, und alle ignorieren es.“ Die instabilen Tests reparieren oder in Quarantäne nehmen, jeden Tag eine Person für einen roten Build verantwortlich machen und Fehler leicht lesbar machen.

Wie gehst du mit Testdaten und Testumgebungen um?

Worauf sie achten: dass du weißt, dass die meisten instabilen Tests und blockierten Tester von Daten und Umgebungen kommen.

Kurze Antwort: „Jeder Test legt die Daten an, die er braucht, und räumt danach auf, wo möglich über die API. Umgebungen werden jedes Mal gleich aufgebaut, am besten in Containern. Echte Kundendaten bleiben aus den Testsystemen heraus oder werden vorher anonymisiert.“

Die ausführliche Antwort: Geteilte Testkonten, die alle verändern, sind die klassische Ursache für Tests, die ohne Grund fehlschlagen. Ich erzeuge Daten im Code, gebe ihnen eindeutige Namen und setze die Datenbank zwischen den Läufen zurück, wo ich kann. Für Systeme, die wir nicht selbst starten können, nutze ich Stubs. Für personenbezogene Daten gilt die DSGVO (das EU-Datenschutzrecht), und ähnliche Gesetze anderswo, auch in Testsystemen; Kopien der Produktion werden deshalb anonymisiert oder durch erfundene Daten ersetzt.

Schwache Antwort: „Wir testen auf einer Kopie der Produktion.“ Nachfrage: „Zwei Teams teilen sich eine Testumgebung und machen sich gegenseitig die Tests kaputt.“ Eigene Umgebungen pro Änderung oder wenigstens eigene Daten pro Team.

Fehler und Fehlermanagement

Was macht einen guten Fehlerbericht aus, und wie managst du Fehler im Team?

Worauf sie achten: klare Kommunikation und ein Ablauf, der die richtigen Fehler behebt.

Kurze Antwort: „Ein guter Fehlerbericht lässt einen Entwickler das Problem in einer Minute sehen: ein klarer Titel, die Schritte, was passiert ist und was hätte passieren sollen, Version und Umgebung und ein Beleg wie ein Screenshot oder ein Log. Dann vereinbart das Team, wie schwer er wiegt und wann er behoben wird.“

Die ausführliche Antwort: Ein Defect (ein anderes Wort für Fehler) hat einen Lebenslauf: gefunden, gemeldet, getriagt (angeschaut und priorisiert), behoben, geprüft, geschlossen. Ich trenne Schweregrad, wie schlimm die Wirkung ist, von Priorität, wie schnell er behoben werden muss. Ein Tippfehler auf der Startseite kann einen niedrigen Schweregrad und eine hohe Priorität haben. Ich halte die Liste kurz: Duplikate zusammengeführt, alte kleine Fehler mit Begründung geschlossen. Jeder behobene Fehler, der wiederkommen könnte, bekommt eine automatisierte Prüfung. Muster zählen mehr als einzelne Fehler: Wenn viele Fehler aus einem Teil kommen, braucht dieser Teil bessere Tests oder einen neuen Entwurf. Das Werkzeug ist oft Jira.

Schwache Antwort: „Ich schreibe ‚Checkout kaputt‘ und weise es dem Entwickler zu.“ Nachfrage: „Ein Entwickler sagt, dein Fehler lässt sich nicht nachstellen.“ Setz dich mit ihm zusammen, vergleicht Umgebungen und Daten und ergänze das fehlende Detail im Bericht.

Du findest am Tag vor einem Release einen schweren Fehler. Was tust du?

Worauf sie achten: ruhiges Urteil, und dass du informierst, statt allein zu entscheiden.

Kurze Antwort: „Ich bestätige ihn schnell, finde heraus, wen und was er betrifft, und sage es sofort den Leuten, die entscheiden, mit den Fakten und den Optionen: beheben und neu testen, ohne die Funktion ausliefern oder verschieben. Ich gebe meine Empfehlung, aber die Entscheidung über das Release trifft das Team oder das Business.“

Die ausführliche Antwort: Erst die Fakten: Kann ich ihn nachstellen, wie viele Nutzer treffen auf ihn, gehen Daten verloren oder gibt es ein rechtliches Risiko, gibt es einen Workaround? Dann die Optionen mit ihren Risiken: Ein kleiner Fix braucht einen gezielten Retest des Bereichs drum herum; eine Funktion mit einem Feature-Flag (einem Schalter im Code) abzuschalten, kann sicherer sein als ein hastiger Fix. Danach fragen, warum der Fehler so spät gefunden wurde, und die Prüfung ergänzen, die ihn früher erkannt hätte.

Schwache Antwort: „Ich blockiere das Release.“ Oder: „Ich trage ihn ein und lasse die anderen entscheiden.“ Nachfrage: „Die Führungskraft liefert trotzdem aus.“ Sorg dafür, dass das Risiko schriftlich festgehalten und akzeptiert ist, bereite den Rollback vor und beobachte die Funktion nach dem Release genau.

Testplanung, Kennzahlen und Teamführung

Diese Fragen kommen für Senior-Softwaretester, Testleads und Testmanager.

Wie schreibst du einen Testplan für ein Release?

Worauf sie achten: dass ein Testplan eine Arbeitsvereinbarung über Umfang, Risiko, Menschen und Zeit ist, kein langes Dokument, das niemand liest.

Kurze Antwort: „Der Testplan sagt, was wir testen und was nicht, welche Risiken es gibt und wie wir sie abdecken, wer was macht, welche Umgebungen und Daten wir nutzen, den Zeitplan und die Regeln für Start, Abbruch und Release. Ich halte ihn kurz und stimme ihn mit dem Team und dem Fachbereich ab.“

Die ausführliche Antwort: Die Strategie ist der allgemeine Ansatz; der Plan wendet sie auf ein Release an. Ich schreibe den Umfang und was nicht dazugehört, die geordneten Risiken, welche Tests jedes abdecken, die Eingangskriterien (was bereit sein muss, bevor das Testen beginnt) und die Endekriterien (was erfüllt sein muss, um auszuliefern, etwa keine offenen kritischen Fehler und die wichtigsten Abläufe grün). Ich liste die Abhängigkeiten auf und was passiert, wenn sie sich verzögern. Ich überarbeite den Plan, wenn sich das Release ändert, und berichte den Fortschritt an den Risiken, nicht an der Zahl der ausgeführten Testfälle.

Schwache Antwort: „Ich fülle die Vorlage der Firma aus.“ Nachfrage: „Die Entwicklung ist zwei Wochen im Verzug, und der Termin steht fest.“ Nach Risiko neu planen, offen vereinbaren, was weniger getestet wird, und Optionen anbieten, etwa den riskanten Teil hinter einem Schalter auszuliefern.

Welche Qualitätskennzahlen verfolgst du, und welche vermeidest du?

Worauf sie achten: dass du Ergebnisse misst und weißt, wie sich Zahlen schönen lassen.

Kurze Antwort: „Ich verfolge, was uns etwas über die Qualität für die Nutzer und die Geschwindigkeit der Rückmeldung sagt: Fehler, die beim Kunden ankommen, wie schnell sie gefunden und behoben werden, den Anteil der Änderungen, die ein Problem verursachen, wie lange die Pipeline braucht, und die Flaky-Rate. Testfälle oder Fehler pro Tester zähle ich nicht, weil die Leute dann der Zahl hinterherlaufen.“

Die ausführliche Antwort: Gute Kennzahlen: Escaped Defects (Fehler, die nach dem Release gefunden werden) und ihr Schweregrad; die Zeit bis zum Finden und Beheben; die Change Failure Rate (wie oft ein Release einen Fix oder einen Rollback braucht); die Laufzeit der Pipeline; die Flaky-Rate; und die Abdeckung der größten Risiken, nicht nur die Codeabdeckung. Codeabdeckung sagt, welche Zeilen während der Tests gelaufen sind, nicht, ob die Tests das Richtige prüfen. Ich zeige Trends über Monate und immer mit Kontext, und ich nutze Kennzahlen, um Fragen zu stellen, nie, um Menschen zu ranken.

Schwache Antwort: „Anzahl ausgeführter Testfälle und gefundener Fehler pro Tester.“ Nachfrage: „Die Geschäftsleitung will eine einzige Zahl für Qualität.“ Biete den Trend der Escaped Defects an, erklärt mit zwei oder drei stützenden Zahlen.

Wie führst du ein Testteam und hilfst Testern, sich zu entwickeln?

Worauf sie achten: bei Rollen als Testlead und Testmanager Personalführung ebenso wie Testen.

Kurze Antwort: „Ich sorge dafür, dass jeder Tester die Prioritäten und ihre Gründe kennt, räume aus dem Weg, was ihn blockiert, und gebe Raum, einen Bereich selbst zu verantworten. Ich führe regelmäßige Einzelgespräche, gebe ehrliches Feedback und plane die Entwicklung jeder Person, zum Beispiel einen manuellen Tester, der Schritt für Schritt Automatisierung lernt.“

Die ausführliche Antwort: In der Praxis: klare Ziele für das Quartal, verknüpft mit den Risiken des Produkts; Tester in den Entwicklungsteams statt in einem eigenen Team am Ende; Pairing und Code-Reviews, um Automatisierungswissen zu verbreiten; ein Lernplan pro Person mit fest eingeplanter Zeit dafür; und ein Mitspracherecht bei Einstellungen. Bei Konflikten mit der Entwicklung bringe ich Daten mit, keine Schuldzuweisungen. Ein Testmanager verantwortet außerdem das Budget, die Werkzeuge und den Einstellungsplan und vertritt die Qualität gegenüber dem oberen Management.

Schwache Antwort: „Ich verteile die Testfälle und prüfe, ob sie erledigt sind.“ Nachfrage: „Ein Tester kommt nicht zurecht, und das Team ist unzufrieden.“ Früh und unter vier Augen sprechen, klare Erwartungen und Unterstützung vereinbaren, nachhalten und handeln, wenn sich nichts ändert.

Wie bringst du Entwickler dazu, Qualität ebenfalls zu verantworten?

Worauf sie achten: dass du Testen als Aufgabe des ganzen Teams siehst und Gewohnheiten ohne Weisungsbefugnis ändern kannst.

Kurze Antwort: „Ich bringe das Testen früher ins Spiel: Ich gehe ins Refinement und schreibe mit dem Team die Akzeptanzkriterien, teste im Pairing mit Entwicklern, mache die Pipeline zu dem Ort, an dem Qualität sichtbar ist, und feiere früh gefundene Fehler, statt spät gefundene zu zählen.“

Die ausführliche Antwort: Das nennt man oft Shift Left, früher in der Arbeit testen. Konkrete Schritte: Beispiele, die vor dem Programmieren vereinbart werden, Unit- und API-Tests in der Definition of Done, Entwickler, die ihre roten Builds selbst reparieren, und Testcode, den beide Seiten reviewen. Manche Teams arbeiten mit testgetriebener Entwicklung. Die Aufgabe des Testers verschiebt sich vom Finden der Fehler am Ende hin zum Helfen, sie zu vermeiden, plus dem Erkunden dessen, was die Automatisierung übersieht.

Schwache Antwort: „Qualität ist Aufgabe des QA-Teams.“ Nachfrage: „Die Entwickler sagen, sie hätten keine Zeit, Tests zu schreiben.“ Zeig die Zeit, die durch späte Fehler und Wiederholungsläufe verloren geht, fang mit einem Team und einer Regel an und teile das Ergebnis.

Dein Lebenslauf für diese Fragen

Jede Antwort oben fällt leichter, wenn dein Lebenslauf sie schon sagt, denn der Interviewer fragt nach dem, was darin steht. Schreib unter jede Stelle zu jedem dieser Punkte eine Zeile, in den Wörtern der Anzeigen:

Skill	Schwache Zeile	Starke Zeile, mit Beleg
Teststrategie	Verantwortlich für das Testen.	Die risikobasierte Teststrategie für eine neue Banking-App geschrieben; im ersten Jahr kam kein kritischer Fehler beim Kunden an.
Automatisierung	Automatisierte Tests mit Cypress.	Eine Cypress- und API-Testsuite mit 600 Prüfungen gebaut; Regressionstests dauern 3 Stunden statt 4 Tage.
CI/CD	CI/CD-Kenntnisse.	Die Pipeline in schnelle und nächtliche Stufen aufgeteilt; erste Rückmeldung zu jeder Änderung in unter 10 Minuten.
Instabile Tests	Die Testsuite gepflegt.	Die Ursachen instabiler Tests gefunden und behoben; rote Builds ohne echten Fehler gingen von täglich auf etwa monatlich zurück.
Testmanagement	QA-Aktivitäten geleitet.	5 Tester in 3 Teams geführt; Escaped Defects in einem Jahr halbiert, bei doppelt so vielen Releases.

Bewerte deinen Lebenslauf dann an einem echten Job: Du siehst, welche dieser Punkte der Job verlangt und welche dein Lebenslauf noch nicht belegt.

Das Wichtigste

Fang jede Antwort beim Risiko an: was schiefgehen kann, wie wahrscheinlich, wie schlimm.
Nutze die Testpyramide als Idee: Teste jedes Risiko auf der günstigsten Stufe, die es erkennt.
Gute Automatisierung ist schnell, stabil und vertrauenswürdig; behebe instabile Tests an der Ursache.
Bring Tests mit klaren Stufen in die Pipeline, mit einer klaren Regel, wann ein Release gestoppt wird.
Für Rollen als Testlead und Testmanager: Bereite Testplanung, ehrliche Kennzahlen und die Förderung von Menschen vor.

Häufige Fragen

Was wird im Vorstellungsgespräch als Softwaretester am häufigsten gefragt?: Wie du entscheidest, was du testest (Strategie, Risiko, Testentwurf), wie du automatisierst (Frameworks, instabile Tests, APIs, CI) und wie du mit Fehlern umgehst. Bei Testlead und Testmanager kommen Planung, Kennzahlen und Menschen dazu.
Gibt es für Softwaretester eine Programmieraufgabe?: Oft, bei Rollen in der Automatisierung und als SDET: eine kleine Übung in der Sprache des Teams, etwa einen Test für eine API schreiben oder einen instabilen Test reparieren. Bei Rollen für manuelles Testen gibt es meist stattdessen Übungen zum Testentwurf.
Welches Framework sollte ich zuerst lernen?: Ein modernes Browser-Werkzeug, Playwright oder Cypress, dazu API-Tests in der Sprache, die du am besten kannst. Die Ideen lassen sich auf Selenium und andere übertragen.
Brauche ich das ISTQB-Zertifikat für das Vorstellungsgespräch?: Nicht, um gut zu antworten, aber seine Begriffe (Äquivalenzklassen, Grenzwerte, Schweregrad und Priorität) sind nützlich, und viele Anzeigen in Europa nennen das Zertifikat.
Wie bereite ich mich in einer Woche vor?: Sag die kurzen Antworten laut, bereite zu jedem Abschnitt eine echte Geschichte vor und übe, Tests für ein einfaches Formular oder eine API zu entwerfen und dabei deine Entscheidungen zu erklären.

So nutzt du diese Fragen

Was ein Softwaretester können muss

Teststrategie und Testentwurf

Wie würdest du eine Teststrategie für ein neues Produkt oder eine große neue Funktion aufbauen?

Was ist die Testpyramide, und hältst du dich immer an sie?

Was ist risikobasiertes Testen, und wie machst du es im Sprint?

Wie würdest du ein Registrierungsformular mit E-Mail, Passwort und Geburtsdatum testen?

Wann setzt du exploratives Testen ein, und wie wird daraus mehr als Herumklicken?

Testautomatisierung und Frameworks

Wie würdest du ein Framework für die Testautomatisierung eines Webprodukts auswählen?

Deine automatisierten Tests schlagen zufällig fehl. Wie gehst du mit instabilen Tests um?

Was automatisierst du, und was testest du weiter von Hand?

Wie testest du eine REST-API?

Tests in der Pipeline

Wie bringst du Tests in eine CI/CD-Pipeline?

Wie gehst du mit Testdaten und Testumgebungen um?

Fehler und Fehlermanagement

Was macht einen guten Fehlerbericht aus, und wie managst du Fehler im Team?

Du findest am Tag vor einem Release einen schweren Fehler. Was tust du?

Testplanung, Kennzahlen und Teamführung

Wie schreibst du einen Testplan für ein Release?

Welche Qualitätskennzahlen verfolgst du, und welche vermeidest du?

Wie führst du ein Testteam und hilfst Testern, sich zu entwickeln?

Wie bringst du Entwickler dazu, Qualität ebenfalls zu verantworten?

Dein Lebenslauf für diese Fragen

Das Wichtigste

Häufige Fragen

Mehr zu diesem Beruf