Senior QA Manual — Manual-QA-Interviewfragen

Du kommst in ein Team ohne jeglichen Testprozess. Was machst du im ersten Monat?

Finde zuerst heraus, wo Qualität tatsächlich wehtut: sprich mit dem Support, lies die Incidents der letzten drei Monate, frag Entwickler, was sie nicht anzufassen wagen. Behebe dann das Günstigste mit der größten Wirkung, meist eine Smoke-Suite auf dem kritischen Pfad plus ein Bug-Workflow, den Leute tatsächlich befolgen. Eine Teststrategie in der ersten Woche zu schreiben, ist der klassische Fehler – niemand liest sie, und die Glaubwürdigkeit dafür hast du dir noch nicht verdient.

Wie rechtfertigst du QA-Personal gegenüber einer Führungskraft, die im Testen nur Kosten sieht?

Hör auf, über Abdeckung zu streiten, und zeig stattdessen, was durchgerutscht ist. Erfasse Defekte, die nach dem Release gefunden wurden, was sie an Support-Zeit, Hotfixes und verlorenen Kunden gekostet haben, und vergleiche das mit den Kosten, sie früher abzufangen. Das Argument, das zieht, ist nicht "wir brauchen mehr Tester", sondern "so viel hat uns kaputte Software letztes Quartal gekostet, und so viel würde es kosten, das größtenteils zu verhindern".

Was würde dich dazu bringen, gegen die Automatisierung eines Tests zu argumentieren?

Wenn sich das Feature noch stark ändert, weil du dann mehr am Test wartest, als er dich schützt. Wenn die Prüfung für einen Menschen günstig und für eine Maschine teuer ist, wie visuelle Beurteilung oder Usability. Wenn der Test von Natur aus flaky ist – Timing, Drittanbieter, echte Zahlungen –, weil ein roter Build, dem niemand traut, schlimmer ist als gar kein Build. Automatisierung zahlt sich auf stabilen, wiederkehrenden, wertvollen Pfaden aus, nicht bei allem.

Ein kritischer Bug hat es bis in die Produktion geschafft. Wie führst du die Nachbesprechung durch?

Schuldfrei und fokussiert auf den Mechanismus, nicht auf die Person. Rekonstruiere die Zeitlinie, trenne den Auslöser von dem Grund, warum er durchgerutscht ist, und frag, warum ihn jede Ebene übersehen hat – Anforderungen, Review, Tests, Umgebung. Das Ergebnis ist eine kleine Zahl konkret zugewiesener Änderungen, keine Entscheidung "vorsichtiger sein". Wenn dieselbe Bugklasse zweimal durchgerutscht ist, liegt der Defekt im Prozess, nicht beim Tester.

Wie entscheidest du, welche Qualitätsmetriken du berichtest, und welche lügen?

Nützliche Metriken beantworten eine Frage, auf die jemand reagieren wird: entkommene Defekte, Zeit bis zur Entdeckung, Flakiness-Rate, Abdeckung kritischer Abläufe. Anzahl der Testfälle und Anzahl gefundener Bugs sind die klassischen irreführenden Metriken, weil beide belohnen, mehr von irgendetwas zu produzieren, statt das Wichtige zu finden – und beide steigen, wenn die Qualität sinkt. Jede Metrik, die du berichtest, wird optimiert werden, also berichte nur solche, deren Manipulation du verkraften kannst.

Product will QA aus dem Sprint streichen, um einen Termin zu halten. Wie reagierst du?

Nicht mit einer Ablehnung, sondern mit einem Tausch. Benenne konkret, was nicht geprüft wird und was davon Nutzer erreichen könnte, in ihrer Sprache – Umsatz, Support-Last, Reputation. Biete einen kleineren Umfang an, den du wirklich abdecken kannst, statt so zu tun, als würde der volle Umfang passen. Ziel ist, dass die Entscheidung mit sichtbarem Risiko getroffen wird; wird trotzdem released, ist das eine legitime Geschäftsentscheidung, und sie ist jetzt dokumentiert.