Vorstellungsgespräch Fragen: 10 praktische Antworten zum manuellen Testen

Beginne mit diesen zehn Fragen und passe die Beispielantworten an Tätigkeiten an, die du ehrlich erklären kannst. Bei Fragen im Vorstellungsgespräch zum Softwaretesten solltest du die Anforderung, die Eingabe, das erwartete Ergebnis und den Grund für deine Entscheidung miteinander verknüpfen.

1. Wie würdest du ein Mengenfeld testen?

Beispielantwort: „Ich würde die zulässigen Werte und das Verhalten beim Absenden klären und dann akzeptierte und abgelehnte Mengen sowie die Grenzwerte testen. Bei einem ganzzahligen Bereich von 1 bis 10 würde ich 0, 1, 10 und 11 prüfen und jeweils ein konkretes erwartetes Ergebnis festlegen.“

2. Worin unterscheiden sich Äquivalenzklassenbildung und Grenzwertanalyse?

„Bei der Äquivalenzklassenbildung gruppiert man Eingaben, von denen man eine ähnliche Behandlung erwartet. Die Grenzwertanalyse prüft die Grenzen geordneter Klassen. Bei einer Menge würde ich 5 als gewöhnlichen gültigen Wert auswählen und dann prüfen, ab wann sich die Akzeptanz rund um 1 und 10 ändert.“

3. Was gehört in einen Testfall?

„Der Testfall muss so genau sein, dass eine andere Testperson die Prüfung wiederholen kann. Für den Checkout würde ich den Ausgangszustand des Warenkorbs, den Kontostatus, die Menge, die Aktion und den erwarteten Bestellgesamtbetrag angeben. Anschließend würde ich das beobachtete Ergebnis dem getesteten Build zuordnen.“

4. Wie würdest du zusammenwirkende Geschäftsregeln testen?

„Vor der Auswahl von Kombinationen würde ich die Bedingungen und erwarteten Aktionen auflisten. Wenn für den Checkout sowohl Bestand als auch eine genehmigte Zahlung erforderlich sind, würde ich beide Bedingungen gemeinsam abdecken, einschließlich eines verfügbaren Artikels mit abgelehnter Zahlung.“

5. Wann ist der Zustand relevant?

„Ich würde dieselbe Aktion aus unterschiedlichen Ausgangszuständen testen. Eine Bestellung aus einem bereiten Warenkorb abzusenden kann gültig sein. Ein erneutes Absenden während einer laufenden Zahlung sollte dagegen einer vereinbarten Regel für doppelte Übermittlungen folgen.“

6. Was testest du nach der Behebung eines Fehlers?

„Ein Bestätigungstest führt die ursprüngliche fehlgeschlagene Prüfung erneut aus, um die Korrektur zu bestätigen. Ein Regressionstest prüft auf nachteilige Auswirkungen an anderer Stelle. Nachdem die Ablehnung der Menge 10 korrigiert wurde, würde ich diesen Fehler erneut prüfen und abhängig von der Änderung passende Mengen- und Checkout-Prüfungen auswählen.“

7. Wie würdest du einen zeitweise auftretenden Fehler melden?

„Ich würde die Bedingungen, Versuche, Zeitstempel und Belege festhalten. Wenn der Checkout bei zehn Versuchen zweimal fehlschlug, würde ich diese Beobachtung melden, die erfolgreichen und fehlgeschlagenen Abläufe sichern und meine vermutete Ursache nicht als erwiesene Tatsache darstellen.“

8. Worin unterscheiden sich Schweregrad und Priorität?

„Der Schweregrad beschreibt die Auswirkungen; die Priorität bestimmt, wann der Fehler behoben werden soll. Ich würde den betroffenen Kaufablauf und mögliche Umgehungslösungen beschreiben und die Planung anschließend mit dem Team besprechen, statt meine erste Einstufung als endgültig anzusehen.“

9. Was tust du, wenn die Anforderung unklar ist?

„Ich würde eine konkrete Frage stellen: Zählt die Eingabe von 2,0 als ganzzahlige Menge? Die vereinbarte Auslegung würde ich festhalten und für die erwarteten Testergebnisse verwenden, statt stillschweigend das von mir bevorzugte Verhalten auszuwählen.“

10. Was tust du, wenn zu wenig Zeit bleibt?

„Ich würde mit Fehlern beginnen, die Käufe verhindern oder falsche Abbuchungen verursachen könnten, und anschließend erklären, was ungeprüft bleibt. Mein Update würde den getesteten Build, die Ergebnisse, Lücken und eine Empfehlung nennen, damit die für die Freigabe verantwortliche Person entscheiden kann.“

Leite zuerst beobachtbares Verhalten aus dem Wertebereich ab und benenne erst danach die Testtechniken. Beispielanforderung: Ein Pflichtfeld für die Menge akzeptiert ganzzahlige Werte von 1 bis einschließlich 10. Beim Absenden eines gültigen Werts wird genau diese Menge zum Warenkorb hinzugefügt. Bei einer ungültigen Eingabe erscheint eine Validierungsmeldung zur Menge, und der Warenkorb bleibt unverändert. Gehe davon aus, dass der Bestand ausreicht und der Warenkorb für jeden Fall leer ist.

Vereinbare für diese Übung, dass leere Eingaben, Dezimalzahlen wie 1,5 und Text wie „zwei“ abgelehnt werden. Ob Schreibweisen wie 2,0, führende Nullen oder Leerzeichen am Anfang oder Ende akzeptiert werden, muss durch eine separate Formatierungsregel geklärt werden. Ordne diese Entscheidungen nicht stillschweigend der Anforderung zum ganzzahligen Wertebereich zu.

Verwende drei numerische Äquivalenzklassen: ganze Zahlen unter 1, ganze Zahlen von 1 bis 10 und ganze Zahlen über 10. Wähle Repräsentanten aus und konzentriere dich anschließend auf die Akzeptanzgrenzen. Die Tabelle verbindet einen Wert aus dem Inneren des Bereichs mit Grenzwert- und Eingabeformatprüfungen.

Beispiel für eine mündliche Antwort: „Ich würde den Warenkorb zurücksetzen, 10 eingeben, einmal auf Absenden klicken und überprüfen, ob der Warenkorb 10 Artikel enthält. Danach würde ich ihn zurücksetzen und 11 ausprobieren. Ich erwarte eine Validierungsmeldung und keine Änderung am Warenkorb. Damit prüfe ich die obere Akzeptanzgrenze, ohne einen angezeigten Wert mit einer erfolgreichen Aktualisierung zu verwechseln.“

Wenn die Oberfläche die Eingabe von Buchstaben verhindert, halte dieses Verhalten fest und teste die unterstützten Interaktionswege. Behaupte nicht, eine Eingabe abgesendet zu haben, die du nicht eingeben konntest. Ändert die interviewende Person den Bestand auf acht Artikel, halte inne und kläre, wie die Bestandsregel mit der Mengenbegrenzung zusammenwirkt.

Die Terminologie folgt dem ISTQB-CTFL-Lehrplan v4.0.1, verfasst vom Lehrplanteam für Foundation Level. ISTQB und die Autorinnen und Autoren des Lehrplans werden hier als Quelle und Rechteinhaber genannt. Die ausgearbeiteten Anforderungen und Antworten in diesem Leitfaden sind Beispiele für Vorstellungsgespräche.

Trenne Bedingungen, die ein Ergebnis bestimmen, von der Abfolge, die zu diesem Ergebnis führt. Beispielannahmen: Der Warenkorb enthält einen gültigen Artikel; der Bestand wird vor der Zahlung geprüft; eine Zahlung wird nur angefordert, wenn der Artikel verfügbar ist; eine Bestellung wird erst nach Zahlungsfreigabe bestätigt. Wird die Zahlung abgelehnt, bleibt der Warenkorb für einen weiteren Versuch verfügbar.

Gib in einer kompakten Entscheidungstabelle „nicht angefordert“ an, wenn keine Zahlung stattfinden kann. So erweckst du nicht den Eindruck, eine unmögliche Kombination benötige ein Testergebnis.

Beschreibe als Nächstes die Zustände: Bereit, Zahlung ausstehend, Zahlung fehlgeschlagen und Bestätigt. Gehe die Folge Bereit → Zahlung ausstehend → Zahlung fehlgeschlagen → Zahlung ausstehend → Bestätigt durch. Prüfe bei jedem Schritt den sichtbaren Status und ob eine Bestellung vorhanden ist.

Für einen zweiten Klick während des Zustands „Zahlung ausstehend“ brauchst du eine eigene Regel. Gehe davon aus, dass gemäß Vereinbarung doppelte Übermittlungen ignoriert werden und gleichzeitig der Fortschritt angezeigt wird. Erwartet werden ein Zahlungsversuch und schließlich eine Bestellung, nicht zwei. Erkläre, welche Belege du in der bereitgestellten Testumgebung prüfen müsstest, um dieses Ergebnis festzustellen. Eine deaktivierte Schaltfläche allein beweist nicht, was nachgelagert passiert ist.

Wenn du Fragen im Vorstellungsgespräch zum Softwaretesten beantwortest, erkläre den Zusammenhang deutlich: Eine Bedingungstabelle ordnet Entscheidungen, während die Zustandsfolge Verhalten sichtbar macht, das von vorherigen Ereignissen abhängt. Bitte die interviewende Person, die Erwartungen an Wiederholungsversuche und doppelte Übermittlungen zu bestätigen, bevor du ein Ergebnis als Fehler einstufst.

Benenne zuerst den ursprünglichen Fehler und beschreibe dann, wie weit sich die Änderung möglicherweise auswirkt. Beispiel: Build Q-17 lehnt die Menge 10 ab, obwohl sie laut Anforderung zulässig ist. Build Q-18 enthält die Korrektur. Wiederhole zunächst die aufgezeichneten Schritte in Q-18 unter denselben Ausgangsbedingungen und prüfe das Ergebnis im Warenkorb, statt nur festzustellen, dass keine Fehlermeldung erscheint.

Stelle anschließend eine gezielte Regressionstest-Auswahl zusammen:

• Prüfe 1 und 10 als akzeptierte Grenzwerte sowie 0 und 11 als abgelehnte Nachbarwerte.
• Prüfe 5, um zu erkennen, ob die Korrektur versehentlich nur einen Grenzwert akzeptiert.
• Ändere eine vorhandene Warenkorbposition von 9 auf 10 und prüfe Menge und Gesamtbetrag.
• Entferne die Position und füge sie erneut hinzu, um einen verwandten Warenkorbablauf zu prüfen.
• Schließe den vereinbarten Checkout-Ablauf mit der Menge 10 ab und prüfe die Bestellmenge.

Hat die entwickelnde Person einen Validator geändert, der auch bei der Bearbeitung des Warenkorbs verwendet wird, sollte dieser Ablauf berücksichtigt werden. Ist die Änderung isoliert, besprich eine kleinere Auswahl und berücksichtige weiterhin die Auswirkungen des Fehlers. Frage nach den geänderten Komponenten, statt aus dem Ticket-Titel darauf zu schließen.

Dokumentiere für jede Prüfung ein Ergebnis und verknüpfe es mit der Korrektur und dem Build. Funktioniert die Menge 10 jetzt, aber auch 11 wird akzeptiert, melde den neuen Fehler. Dass das ursprüngliche Symptom verschwunden ist, reicht nicht aus, um alle Tests abzuschließen. Beende deine Antwort mit dem verbleibenden Prüfumfang und allen blockierten Prüfungen.

Gib der interviewenden Person einen Bericht, den sie direkt an ein Teammitglied weitergeben könnte. Beispiel für einen Fehlerbericht: Die Mengenanforderung gilt weiterhin für den Bereich von 1 bis einschließlich 10, doch die Testumgebung lehnt den oberen Grenzwert ab. Die folgenden Kennungen und Beobachtungen gehören zu diesem Beispiel.

ID: QTY-24
Titel: Menge 10 wird beim Hinzufügen eines verfügbaren Artikels abgelehnt
Beobachtet: 2026-11-05
Meldende Person: Alex, manuelle Testperson
Status: Offen
Build: Q-17
Umgebung: QA-Storefront, Desktop-Browser; genaue Version beigefügt
Referenz: Anforderung QTY-01; Testfall QTY-BOUNDARY-10
Vorbedingungen: Leerer Warenkorb; angemeldetes Testkonto; Artikelbestand: 20
Daten: Menge 10; Artikel TEST-MUG

Schritte:
1. Produktseite von TEST-MUG öffnen.
2. Bei Menge 10 eingeben.
3. Einmal „In den Warenkorb“ auswählen.
4. Validierungsmeldung und Warenkorb prüfen.

Erwartet: Keine Mengen-Validierungsmeldung; Warenkorb enthält 10 Artikel vom Typ TEST-MUG.
Tatsächlich: Mengen-Validierungsmeldung erscheint; Warenkorb bleibt leer.
Reproduktion: 3 Fehler bei 3 Versuchen; Warenkorb jedes Mal zurückgesetzt.
Auswirkung: Kundinnen und Kunden können die maximal zulässige Menge nicht mit einer Aktion hinzufügen.
Beobachtete Umgehungslösung: Zweimaliges Hinzufügen von jeweils 5 ergibt eine Warenkorbmenge von 10.
Vorgeschlagener Schweregrad: Mittel nach der Auswirkungsskala dieses Teams.
Vorgeschlagene Priorität: Vor der Verkaufsaktion für Großbestellungen im Triage besprechen.
Belege: Screenshot der Meldung; Sitzungsaufzeichnung; Zeitstempel beigefügt.

Ersetze in einem echten Bericht den Platzhalter für die Umgebung und füge die genannten Belege bei. Behandle Kontodaten und Aufzeichnungen gemäß den Regeln des Teams. Nenne eine vermutete Ursache separat: „Mögliches Problem beim Vergleich mit dem oberen Grenzwert“ ist ein Hinweis, kein beobachtetes Ergebnis.

Besprich Auswirkungen und Zeitplanung im jeweiligen Kontext. Die Umgehungslösung kann die unmittelbare Beeinträchtigung verringern, während eine bevorstehende Verkaufsaktion die Fehlerbehebung dringlicher machen kann. Andere Teams verwenden möglicherweise andere Einstufungen. Erkläre zuerst die Folgen für Kundinnen und Kunden und den zeitlichen Kontext und ordne beides anschließend der lokalen Skala zu. Kann die entwickelnde Person den Fehler nicht reproduzieren, vergleicht gemeinsam Build, Daten, Konto und Ablauf, bevor ihr den Ticketstatus ändert.

Mach aus Unsicherheit eine konkrete Entscheidungsfrage. Beispiel: „Im Ticket steht, dass Kundinnen und Kunden die Zahlung erneut versuchen können. Es steht aber nicht darin, ob die Warenkorbreservierung nach einer abgelehnten Zahlung bestehen bleibt. Soll der Bestand beim erneuten Versuch nochmals geprüft werden?“ Halte die Antwort neben der Anforderung fest und aktualisiere die erwarteten Ergebnisse. Bis dahin solltest du die Erwartung als ungeklärt kennzeichnen, statt die Prüfung als bestanden zu zählen.

Schlage unter Zeitdruck eine Reihenfolge vor, die sich am möglichen Schaden und an der betroffenen Funktion orientiert. Beginne beim Checkout-Beispiel mit der Erstellung der Bestellung, fehlgeschlagenen Zahlungen, doppelten Übermittlungen und den Mengensummen. Prüfe anschließend Details mit geringeren Auswirkungen, sofern Zeit bleibt. Verhindert eine fehlende Einrichtung eine risikoreiche Prüfung, eskaliere das Hindernis und führe währenddessen sinnvolle unabhängige Tests durch.

Fasse das Freigabe-Update in vier Punkten zusammen: Was wurde getestet, was ist passiert, was ist unbekannt und welche Entscheidung wird benötigt?

Beispiel: „In Q-18 haben die Prüfungen akzeptierter und abgelehnter Mengen bestanden; bei einem Checkout mit genehmigter Zahlung wurde die erwartete Bestellung erstellt. Der Wiederholungsversuch nach einer abgelehnten Zahlung ist blockiert, weil die Testzahlungseinrichtung nicht verfügbar ist. Ich empfehle, diese Einrichtung wiederherzustellen und die Prüfung des Wiederholungsversuchs vor der Freigabe abzuschließen. Wird jetzt freigegeben, bleibt der Wiederholungsablauf ein ausdrückliches Risiko, das die für die Freigabe verantwortliche Person akzeptieren muss.“

Formuliere „Bei den durchgeführten Prüfungen gab es keine Fehler“ nicht zu „Das System hat keine Fehler“ um. Unterscheide bestandene, fehlgeschlagene, blockierte und nicht ausgeführte Prüfungen. Erkläre bei Fragen im Vorstellungsgespräch zum Umgang mit Meinungsverschiedenheiten, wie du Belege mit einer entwickelnden Person abgleichen und ungeklärtes Geschäftsverhalten an die zuständige entscheidende Person herantragen würdest. Schließe mit einer konkreten nächsten Aktion, etwa die fehlende Einrichtung zu organisieren oder die Regel für Wiederholungsversuche zu klären.

Nutze SayNow AI, um deine Testentscheidungen klar auszusprechen. Das KI-Probeinterview bietet ein Sprachgespräch mit Fragen und Rückfragen. Anschließend erhältst du eine Bewertung und Vorschläge zu Sprachfluss, Inhaltsstruktur, Passung zum Szenario und Zielerreichung.

Bereite ein technisch überprüftes Beispiel aus diesem Leitfaden vor, bevor du das Szenario „Vorstellungsgespräch“ öffnest. Beginne deine gesprochenen Antworten mit der Entscheidung, erkläre die relevante Anforderung und nenne das erwartete Ergebnis. Nutze STAR für eine frühere Erfahrung, etwa die Untersuchung eines umstrittenen Fehlers. Wenn das Gespräch einen unklaren Punkt aufgreift, antworte direkt, statt deine ganze Geschichte neu zu beginnen.

Wähle danach eine Änderung aus dem Feedback aus: Nenne das erwartete Ergebnis früher, kürze den Hintergrund oder beschreibe deinen eigenen Beitrag klarer. Übe mit dieser Änderung erneut. SayNow AI prüft nicht, ob deine Aussagen fachlich korrekt sind. Gleiche deine Testüberlegungen separat mit der Anforderung und einer sachkundigen Testperson ab. Nutze die Sprechbewertung ausschließlich als Feedback für deine Übung.

Übe deine Erklärung für das Vorstellungsgespräch im entsprechenden Szenario.

Mache eine letzte Übung mit einer veränderten Bedingung, statt jeden Satz auswendig zu lernen. Bitte eine Übungspartnerin oder einen Übungspartner, die Mengenbegrenzung zu ändern, die Umgehungslösung wegzunehmen oder nach den Belegen für einen gemeldeten Fehler zu fragen. Deine Aufgabe ist es, die Testerwartung anzupassen und die Konsequenz zu erklären.

Prüfe deine Antwort anhand dieser Checkliste:

• Kann die zuhörende Person die Anforderung und die Annahmen erkennen?
• Hast du konkrete Testdaten und ein beobachtbares erwartetes Ergebnis genannt?
• Kann jemand den Fehlerbericht anhand seiner beschriebenen Ausgangsbedingungen wiederholen?
• Hast du nach der Änderung erklärt, warum die ausgewählten Tests wichtig sind?
• Hast du beobachtete Ergebnisse, vermutete Ursachen und ungeklärte Fragen voneinander getrennt?
• Hast du die nächste Aktion und die Person genannt, die diese Informationen benötigt?

Bereite für Fragen im Vorstellungsgespräch für Positionen im Softwaretesten neben den technischen Beispielen eine Geschichte aus einem Projekt vor. Beschreibe deinen eigenen Beitrag und das Ergebnis, das du tatsächlich beobachtet hast. Nutze die passenden Leitfäden zu Verhaltensfragen und zur STAR-Methode, damit deine Geschichte fokussiert bleibt.

Gute Antworten auf Fragen zum manuellen Testen im Vorstellungsgespräch verknüpfen eine klare Anforderung mit gezielten Eingaben, erwarteten Ergebnissen und einer begründbaren nächsten Entscheidung. Übe das Mengenbeispiel, passe den Fehlerbericht an eine Erfahrung an, über die du ehrlich sprechen kannst, und erkläre das Risiko, das nach deinen ausgewählten Prüfungen bestehen bleibt.