Senior QA Automation — QA-Automation-Interviewfragen

Wie rechtfertigst du die Kosten der Automatisierung gegenüber jemandem, der dafür bezahlt?

In Begriffen, die diese Person schon verwendet: Kosten pro Release, Zeit von Commit bis Vertrauen, Defekte, die Kunden erreichen. Eine Suite, die zwei Ingenieure einen Monat kostet und zehn manuelle Stunden pro Release spart, amortisiert sich bei wöchentlichem Rhythmus und nicht bei quartalsweisem – die Rechnung unterscheidet sich von Team zu Team und sollte gezeigt, nicht behauptet werden. Der ehrliche Teil der Antwort ist zu benennen, was nicht automatisiert wird und warum.

Du erbst eine Suite von 800 Tests, die vier Stunden läuft und in der Hälfte der Fälle fehlschlägt. Was machst du zuerst?

Messen, bevor du irgendetwas anfasst: welche Tests am häufigsten fehlschlagen, welche am längsten laufen, welche noch nie einen echten Defekt gefangen haben. Meist entfällt der Großteil des Schmerzes auf eine kleine Zahl. Stelle die flaky Tests unter Quarantäne, damit der Build wieder grün wird und das Team ihm wieder zu vertrauen beginnt, und behebe oder lösche sie dann. Löschen ist eine echte Option – ein Test, dem niemand vertraut, hat einen negativen Wert, weil er Aufmerksamkeit kostet und nichts liefert.

Wann hilft BDD und wann macht es die Sache schlimmer?

Es hilft, wenn Nicht-Entwickler die Szenarien wirklich lesen und schreiben, was selten vorkommt und jemanden braucht, der die Sprache verantwortet. Es macht die Sache schlimmer, wenn das Team Gherkin nur für sich selbst schreibt: Dann entsteht eine englische Schicht über dem Code, die niemand von außen liest, plus eine Step-Definition-Indirektion, die aus einer Zwei-Zeilen-Änderung eine Suche macht. Wenn der Product Owner die Feature-Files nie öffnet, solltest du sie weglassen.

Wie wählst du Tooling für etwas aus, das du jahrelang pflegen wirst?

Gewichte das, was teuer zu ändern ist: die Sprache, die das Team bereits schreibt, wie das Tool mit Waits umgeht, ob es in CI ohne Display laufen kann, und wie gesund das Projekt ist – Release-Rhythmus, Alter offener Issues. Geschwindigkeitsbenchmarks zählen am wenigsten, weil die Laufzeit der Suite von deiner Anwendung dominiert wird, nicht vom Driver. Frag, was passiert, wenn das Tool aufgegeben wird.

Was macht einen Testreport zu einem, den jemand tatsächlich liest?

Ein Fehlschlag, der sagt, was kaputt ist, statt nur, dass eine Assertion false zurückgegeben hat: der Schritt, der Screenshot, das Netzwerklog, der Unterschied zwischen erwartet und tatsächlich. Gruppierung nach vermuteter Ursache statt nach Datei zählt mehr als das Styling. Das eigentliche Maß ist, ob ein Ingenieur in dreißig Sekunden entscheiden kann, ob der Fehlschlag sein Problem ist – dauert es länger, wird der Report übersprungen.

Wie misst du, ob die Automatisierung funktioniert?

Zuerst entkommene Defekte – Bugs, die in einem von Tests abgedeckten Bereich die Produktion erreicht haben, denn genau das soll die Suite verhindern. Dann die Flakiness-Rate und die Zeit von Commit bis zu einem vertrauenswürdigen Signal. Der Abdeckungsprozentsatz ist die Metrik, der du misstrauen solltest: Er lässt sich leicht erhöhen, ohne etwas Sinnvolles zu testen, und ein Team, dem gesagt wird, ihn zu erhöhen, wird genau das tun.