QA-Engineer auswählen: Risiken, Teststrategie und Arbeitsprobe

Klären Sie, welche Qualitätsrisiken die Rolle bearbeiten soll

QA kann manuelle Untersuchung, Testanalyse, Automatisierung, Releasebegleitung oder die Verbesserung von Entwicklungsabläufen umfassen. Beschreiben Sie, welche Entscheidungen die Person treffen darf und welche Probleme heute auftreten. Werden Fehler erst nach einer Veröffentlichung gefunden? Fehlen reproduzierbare Tests? Ist unklar, was vor einem Release geprüft werden muss?

Ein brauchbarer Auftrag benennt Produktbereich, Risiken, Werkzeuge und Zusammenarbeit. Zum Beispiel: „Für den Zahlungsablauf sollen die wichtigsten Risiken sichtbar werden. Gemeinsam mit Entwicklung und Produkt legen Sie eine wiederholbare Prüfung fest und automatisieren geeignete stabile Abläufe.“ So erwarten Sie nicht, dass ein einzelner QA-Engineer allein für die Produktqualität haftet.

Der ISTQB-Lehrplan beschreibt Testanalyse als Ableitung prüfbarer Bedingungen aus einer Testbasis und die Priorisierung unter Berücksichtigung von Risiken. Diese Begriffe helfen beim Gespräch, ersetzen aber kein Urteil über die konkrete Rolle und belegen keine praktische Eignung. ISTQB CTFL Syllabus

Geben Sie eine kleine, risikobezogene Arbeitsprobe

Nutzen Sie ein fiktives Formular oder einen eigens vorbereiteten Ablauf. Nennen Sie die fachlichen Regeln, lassen Sie aber bewusst einige Details offen. Bitten Sie die Person, Rückfragen zu stellen, Risiken zu priorisieren, passende Prüfungen vorzuschlagen und einen Befund verständlich aufzuschreiben. Vermeiden Sie produktive Kundendaten und umfangreiche unbezahlte Arbeit.

Bewerten Sie nicht die Zahl der gefundenen Fehler. Eine Person kann viele nebensächliche Auffälligkeiten auflisten und gleichzeitig den schwerwiegenden Fall übersehen. Bitten Sie darum, die Reihenfolge zu erklären und zu benennen, welche Information die Priorität noch ändern würde.

Werten Sie jedes Kriterium mit einem beobachtbaren Beleg: belegt (die Entscheidung wurde erklärt und an der Aufgabe gezeigt), teilweise belegt (Ansatz ist plausibel, aber ein wichtiger Fall oder eine Begründung fehlt), noch nicht gezeigt (die Aussage blieb allgemein oder passte nicht zum Risiko). Notieren Sie zu jeder Einstufung, was die Person konkret gezeigt hat.

Fiktives Beispiel: Ein Duplikat kann schwerer wiegen als ein Anzeigeproblem

Fiktives Beispiel, kein realer Kundenfall: Ein Checkout zeigt nach einem langsamen Netzwerk keine Bestätigung. Zwei Beobachtungen sind möglich: Der Button hat im Fehlerfall einen schlecht lesbaren Farbton, und ein erneuter Klick kann eine zweite Bestellung auslösen. Eine Bewerberin priorisiert zuerst den zweiten Fall, weil er zu einer doppelten Belastung führen kann. Sie fragt, ob serverseitige Wiederholungen und Rückmeldungen an den Nutzer Teil des Auftrags sind.

Ein guter Bericht trennt beobachtetes Verhalten von vermuteter Ursache. Er enthält genug Angaben, damit eine andere Person den Fehler mit derselben Testumgebung nachstellen kann.

Das ist ein starkes Urteil für diese Aufgabe: Die Person verbindet den Test mit einer plausiblen Auswirkung, grenzt die eigene Annahme ein und benennt den nötigen Klärungspunkt. Die genaue technische Ursache bleibt offen. Sie sollte mit Entwicklung und Produkt untersucht werden. Ein belastbarer QA-Bericht zeigt, was beobachtet wurde, nicht bloß eine vermutete Ursache.

Fragen Sie nach konkreten Beispielen statt nach Testvokabeln

• „Erzählen Sie von einem Fehler, den Sie früh entdeckt haben. Welches Risiko stand dahinter?“
• „Wie gehen Sie vor, wenn Anforderungen unvollständig oder widersprüchlich sind?“
• „Welche wiederholte Prüfung würden Sie automatisieren und welche bewusst manuell untersuchen?“
• „Welche Angaben machen einen Fehlerbericht für eine Entwicklerin sofort nutzbar?“
• „Wie würden Sie Release-Risiken kommunizieren, wenn nicht alle Tests abgeschlossen sind?“
• „Was muss im Team passieren, damit Fehler nicht erst kurz vor der Veröffentlichung auffallen?“

• Teilen Sie Rollen, Aufgaben, Testumgebung und erlaubte Werkzeuge vorab mit.
• Geben Sie für die Arbeitsprobe gleiche Regeln zur Nutzung von Dokumentation und KI vor. Fragen Sie nach Kontrolle und Grenzen der erzeugten Vorschläge.
• Prüfen Sie, ob die Person Tests erklären kann, ohne nur Methoden- oder Werkzeugnamen aufzuzählen.
• Klären Sie, wer Fehlerpriorität, Releasefreigabe und Produktentscheidungen verantwortet.

QA unterstützt Ihre Qualitätsentscheidung, übernimmt sie nicht

Ein Arbeitsprobenergebnis belegt nicht, wie eine Person in Ihrer Codebasis, mit Ihren Releasewegen und unter Zeitdruck arbeitet. Ein Zertifikat kann gemeinsames Wissen strukturieren, beweist aber nicht allein die praktische Ausführung. Prüfen Sie fachliche Beispiele, Gesprächsverhalten und die konkrete Zusammenarbeit. Fragen Sie bei jeder Bewertung nach dem Beleg und der offenen Unsicherheit.

Ihr Team bleibt verantwortlich für Produktregeln, technische Entscheidungen, Zugänge und Releasefreigaben. QA kann Risiken benennen, Prüfungen planen und Befunde reproduzierbar machen. Welche Befunde ein Release verhindern, entscheiden die dafür benannten Verantwortlichen.

Division5 gleicht Aufgaben mit vorab geprüften Profilen ab. Sie können die geprüften Profile und aufgezeichneten Interviews schon vor dem Kennenlernen ansehen. Für alle Fachkräfte gilt eine 30-tägige Testphase; Umfang und Bedingungen halten Sie vor Beginn schriftlich fest. Verfügbarkeit wird für Ihre Anfrage geprüft. So läuft der Auswahlprozess ab.

Fachkräfte für Ihr Team ansehen oder den Auswahlprozess kennenlernen.