Ein Manual-QA-Interview prüft dein Verständnis von Testtheorie und Testdesign-Techniken sowie deine Fähigkeit, Bugreports zu schreiben, mit denen Entwickler tatsächlich etwas anfangen können. Hier sind die häufigsten Fragen auf Junior- und Middle-Niveau, jeweils mit einer Musterantwort. Middle: tieferes Verständnis, Optimierung und reale Arbeitssituationen.
Du wählst nach Risiko aus, nicht nach Abdeckung. Das heißt: was sich in diesem Release geändert hat und was davon betroffen ist, die Abläufe, deren Ausfall Geld kostet – Login, Checkout, Zahlung – und die Bereiche mit der reichsten Fehlerhistorie. Und du sagst laut, was du nicht ausgeführt hast, damit die Entscheidung zu releasen die des Teams ist und nicht stillschweigend deine.
Das entscheidest du nicht allein, aber du bereitest es auf: wie viele Nutzer betroffen sind, wie oft, ob es einen Workaround gibt, was der Fix selbst zu riskieren droht. Ein kosmetischer Versatz auf einem selten genutzten Screen bei einem Release morgen ist ein legitimes "nicht jetzt". Nicht legitim ist es, ihn still zu schließen – er gehört mit Begründung ins Backlog, sonst wird derselbe Bug jedes Quartal neu gefunden.
Geh zuerst davon aus, dass sich die Umgebungen unterscheiden, nicht dass der Test falsch ist. Vergleiche Daten, Konfiguration, Feature-Flags, Versionen und Timing – Staging ist meist langsamer, was Race Conditions und implizite Wartezeiten offenlegt. Prüfe dann, ob der Test von Zustand abhängt, den ein anderer Test hinterlassen hat. Ihn als flaky abzustempeln und einfach neu zu starten, macht aus einem echten Umgebungsbug einen dauerhaft ignorierten roten Test.
Statuscodes für Erfolg und Fehler, das Antwortschema und die Typen, Pflicht- gegen optionale Felder, und was bei fehlenden, zusätzlichen oder falsch typisierten Feldern passiert. Danach die Autorisierung – dieselbe Anfrage ohne Token und mit dem Token einer anderen Person. Zum Schluss die Grenzfälle: leere Arrays, riesige Payloads und wiederholte Aufrufe, denn Idempotenz ist der Ort, an dem sich API-Bugs verstecken.
Du wartest nicht auf perfekte Anforderungen, sondern machst die Unklarheit sichtbar. Schreib auf, wie du sie interpretiert hast, liste die Fälle auf, die die Spec nicht beantwortet, und trage das dem Analysten oder Product Owner vor, bevor du Testfälle auf eine Vermutung baust. Fragen, die vor Ende der Entwicklung gestellt werden, kosten ein Gespräch; dieselben Fragen danach kosten Nacharbeit.
Sie besagt, dass die meisten Prüfungen schnelle Unit-Tests sein sollten, weniger Integrationstests und ganz wenige langsame End-to-End-Tests. Für manuelles QA bedeutet das: Deine Zeit ist verschwendet, wenn du Dinge erneut manuell durchgehst, die ein Unit-Test bereits abdeckt. Manueller Aufwand gehört dorthin, wo Menschen besser sind als Maschinen: exploratives Testen, Usability und Szenarien, an deren Automatisierung niemand gedacht hat.
Ein Bug ist Verhalten, das einer Anforderung, einer Spezifikation oder einer vernünftigen Nutzererwartung widerspricht. Ein Feature-Wunsch verlangt Verhalten, das nie vereinbart wurde. Die Grauzone ist der dritte Fall – die Spec schweigt und das Verhalten ist schlecht –, und darüber zu streiten, wie man es nennt, ist Zeitverschwendung. Beschreibe die Auswirkung, überlass die Einordnung dem Product Owner und sorg dafür, dass sie so oder so nicht verloren geht.
Im echten Interview sprichst du unter Druck. Cam stellt genau diese Fragen, bewertet jede Antwort und zeigt dir genau, was du verbessern musst.
Middle QA Manual-Interview üben →