Manual-QA-Interviewfragen

Was ist der Unterschied zwischen Verifikation und Validierung?

Verifikation fragt: "Bauen wir das Produkt richtig?" – sie prüft die Arbeit gegen Spezifikationen und Designdokumente, meist durch Reviews und statische Analyse. Validierung fragt: "Bauen wir das richtige Produkt?" – sie prüft durch dynamisches Testen, ob die fertige Software das Problem der Nutzer tatsächlich löst. Verifikation begleitet die gesamte Entwicklung, Validierung erfolgt gegen reale Anforderungen und echte Nutzer.

Was ist Äquivalenzklassenbildung? Wende sie auf ein Feld "Alter" an, das Werte von 1–120 akzeptiert.

Äquivalenzklassenbildung teilt Eingabedaten in Gruppen ein, innerhalb derer sich jeder Wert gleich verhalten sollte, sodass es reicht, einen Wert pro Gruppe zu testen. Für ein Altersfeld von 1–120 ergeben sich vier Klassen: gültig 1–120, ungültig darunter (0 und negative Zahlen), ungültig darüber (121+) und ungültiger Typ (Buchstaben, Symbole, leer). Das macht vier Tests statt hundertzwanzig.

Was ist Grenzwertanalyse? Gib ein Beispiel für ein Feld mit dem Bereich 1–100.

Grenzwertanalyse zielt auf die Ränder jeder Äquivalenzklasse, weil sich dort Off-by-one-Fehler häufen. Für ein Feld mit dem Bereich 1–100 testest du 0, 1, 2 am unteren und 99, 100, 101 am oberen Rand. Sie wird fast immer zusammen mit der Äquivalenzklassenbildung eingesetzt: Die Klassen zeigen, welche Gruppen existieren, die Grenzwerte zeigen, wo sie kippen.

Wie unterscheidet sich Severity von Priority? Nenne ein Beispiel für hohe Severity mit niedriger Priority.

Severity beschreibt die technische Auswirkung des Defekts auf das System, Priority beschreibt, wie dringend das Business ihn behoben haben will. Beide werden von unterschiedlichen Personen vergeben – Severity meist vom Tester, Priority vom Product Owner oder Manager. Ein Absturz in einem selten genutzten Admin-Export ist hohe Severity, aber niedrige Priority; ein Tippfehler im Firmennamen auf der Landingpage ist niedrige Severity, aber hohe Priority.

Beschreibe den Bug-Lifecycle. Welche Status kann ein Bug durchlaufen?

Ein Defekt durchläuft typischerweise New → Assigned → Open (in Bearbeitung) → Fixed → Retest → Closed. Alternative Ausgänge sind Rejected (kein Defekt), Duplicate, Deferred (auf ein späteres Release verschoben) und Reopened, wenn ein Retest zeigt, dass der Fix nicht funktioniert hat. Die genauen Status variieren je nach Team, wichtig ist aber, dass jeder Bug in einem Endzustand mit dokumentierter Begründung landet.

Was sind Smoke-, Sanity- und Regressionstests? Worin liegt der Unterschied?

Smoke-Tests sind eine flache, breite Prüfung, ob der Build überhaupt stabil genug zum Testen ist – ist der Login kaputt, wird das Testen gestoppt. Sanity-Tests sind schmal und tief: Nach einem bestimmten Fix wird geprüft, ob genau ein Bereich wie erwartet funktioniert. Regressionstests sind breit und wiederholt: Sie bestätigen, dass neue Änderungen bisher funktionierende Funktionalität nicht kaputt gemacht haben, und sind der Hauptkandidat für Automatisierung.

Was ist exploratives Testen und wie unterscheidet es sich von Ad-hoc-Testen?

Exploratives Testen bedeutet, Tests gleichzeitig zu entwerfen und auszuführen – der Tester lernt das Produkt kennen und entscheidet anhand der Funde, was als Nächstes zu prüfen ist. Es ist strukturiert: Es gibt ein Charter, eine Zeitbox und Notizen. Ad-hoc-Testen ist unstrukturiert und undokumentiert, rein aus dem Bauch heraus. Exploratives Testen ist wiederholbar und berichtbar, Ad-hoc-Testen nicht.

Nenne die Pflichtfelder eines Bugreports. Warum sind Reproduktionsschritte so wichtig?

Ein brauchbarer Bugreport enthält eine klare Zusammenfassung, die Umgebung (Build, Betriebssystem, Browser, Gerät), Voraussetzungen, Schritte zur Reproduktion, das tatsächliche Ergebnis, das erwartete Ergebnis, Severity, Priority sowie Anhänge wie Screenshots oder Logs. Reproduktionsschritte sind am wichtigsten, weil ein Defekt, den ein Entwickler nicht reproduzieren kann, meist als "nicht reproduzierbar" geschlossen wird – der Report verliert dann seinen gesamten Wert.

Was ist ein Testplan und welche Abschnitte enthält er?

Ein Testplan beschreibt, wie das Testen für ein Projekt oder Release durchgeführt wird. Typische Abschnitte sind Umfang (was getestet wird und was nicht), Vorgehen und Teststufen, Eingangs- und Ausgangskriterien, Umgebungen und Testdaten, Rollen und Verantwortlichkeiten, Zeitplan, Risiken mit Gegenmaßnahmen sowie Liefergegenstände. Es ist ein Management-Dokument – das Ziel ist, dass jeder erkennen kann, was von wem getestet wird und wann Testen als abgeschlossen gilt.

Wie würdest du ein Login-Formular testen? Nenne positive und negative Fälle.

Positiv: Gültige Zugangsdaten loggen korrekt ein und leiten richtig weiter, "Angemeldet bleiben" hält die Session aufrecht, das Zurücksetzen des Passworts funktioniert von Anfang bis Ende. Negativ: falsches Passwort, nicht existierender Nutzer, leere Felder, SQL-Injection- und XSS-Payloads, führende und nachgestellte Leerzeichen, Groß-/Kleinschreibung, extrem lange Eingaben, Sperrung des Kontos nach wiederholten Fehlversuchen. Zusätzlich solltest du nichtfunktionale Aspekte prüfen: Das Passwort ist maskiert, das Formular funktioniert mobil, die Zugangsdaten werden über HTTPS übertragen, und Fehlermeldungen verraten nicht, ob der Benutzername existiert.

Was sind die sieben Testprinzipien nach ISTQB?

Testen zeigt das Vorhandensein von Fehlern, kann aber deren Abwesenheit nicht beweisen; vollständiges Testen ist unmöglich; frühes Testen spart Zeit und Geld; Fehler häufen sich in einer kleinen Zahl von Modulen; das Pestizid-Paradoxon bedeutet, dass wiederholte Tests irgendwann keine neuen Fehler mehr finden; Testen ist kontextabhängig; und der Trugschluss der Fehlerfreiheit besagt, dass Software ohne bekannte Defekte trotzdem unbrauchbar sein kann, wenn sie das falsche Problem löst.

Was ist eine Entscheidungstabelle und wann setzt du sie ein?

Eine Entscheidungstabelle bildet Kombinationen von Eingabebedingungen auf die erwarteten Systemaktionen ab. Du nutzt sie, wenn das Verhalten von mehreren zusammenwirkenden Bedingungen abhängt – zum Beispiel ein Rabatt, der von Kundentyp, Bestellgröße und Promocode abhängt. Sie macht fehlende Kombinationen sichtbar und lässt sich direkt in Testfälle überführen, weshalb sie die Standardtechnik für komplexe Geschäftsregeln ist.

Was ist der Unterschied zwischen einem Testfall und einer Checkliste? Wann verwendest du welche?

Ein Testfall beschreibt genaue Schritte, Testdaten und ein erwartetes Ergebnis – er ist von jedem wiederholbar und eignet sich für regulierte oder komplexe Funktionalität. Eine Checkliste ist eine Liste von zu prüfenden Punkten ohne vorgeschriebene Schritte, die auf das Urteilsvermögen des Testers setzt. Checklisten sind schneller geschrieben und gepflegt und passen zu explorativer Arbeit oder stabilen, gut verstandenen Bereichen; Testfälle passen zu Onboarding, Audits und Features, bei denen der genaue Ablauf entscheidend ist.

Was ist der Unterschied zwischen funktionalem und nichtfunktionalem Testen?

Funktionales Testen prüft, was das System tut – ob sich Features gemäß den Anforderungen verhalten. Nichtfunktionales Testen prüft, wie gut es das tut: Performance, Last, Sicherheit, Usability, Barrierefreiheit, Kompatibilität und Zuverlässigkeit. Nichtfunktionale Defekte sind oft teurer zu beheben, weil sie eher in der Architektur verwurzelt sind als in einer einzelnen Codezeile.