Die Latte für Junior-QA steigt – wofür jede einzelne Anforderung wirklich gut ist

Vor zwölf Jahren konnte der Einstieg ins Testen so aussehen: Man ging zu einer Konferenz, hörte sich einen Vortrag an, sprach danach den Speaker an und stellte eine gute Frage. Eine Woche später kam das Angebot.

Das ist keine Nostalgie. Es war Alltag. Es gab mehr offene Stellen als Leute, die Branche wuchs schneller, als irgendjemand ausbilden konnte, und Unternehmen stellten nach der Fähigkeit zu denken ein – den Rest wollte man on the job beibringen.

Heute verlangt dieselbe Position Testdesign-Techniken, ein Verständnis von HTTP, die Fähigkeit, eine SQL-Abfrage mit Join zu schreiben, eine Vorstellung davon, was XSS und SQL-Injection sind, Erfahrung mit Postman – und immer häufiger den Zusatz „Automatisierung von Vorteil“.

Die erste Reaktion auf diese Liste ist meist: Ist das überhaupt angemessen? Seien wir ehrlich – ein Teil dieser Anforderungen ist berechtigt, ein Teil nicht, und den Unterschied zu kennen lohnt sich.

Warum die Latte gestiegen ist

Das Verhältnis von Bewerbern zu offenen Stellen hat sich umgekehrt. 2013 war jemand mit Englischkenntnissen und Lernbereitschaft rar. Heute bekommt eine Junior-Stelle Hunderte Bewerbungen. Aus dem Gespräch wurde ein Filter, und Filter brauchen Kriterien – am liebsten formale, die sich leicht zwischen Kandidaten vergleichen lassen.

Der Job selbst hat sich verändert. Ein QA-Engineer klickte sich vor zwölf Jahren meist anhand eines Skripts durch die UI und meldete Bugs. Heute öffnet derselbe Junior die DevTools, beobachtet den Network-Tab, geht zu Postman, um zu sehen, was das Backend tatsächlich zurückgegeben hat, und in die Datenbank, um zu prüfen, ob es gespeichert wurde. Nicht weil das gerade angesagt ist, sondern weil Produkte verteilt geworden sind und die Hälfte der Fehler nicht mehr auf dem Bildschirm sichtbar ist.

Die Zeit zum Reinwachsen ist kürzer geworden. Teams sind kleiner, Releases häufiger. Früher hatte ein Junior sechs ruhige Monate, um neben einem Senior zu wachsen. Heute soll er ab dem zweiten Sprint produktiv sein, und Unternehmen versuchen, sich diese Startbereitschaft schon beim Einstellen einzukaufen.

Und ein Teil ist schlicht Anforderungsinflation. Sobald in einer Stellenanzeige „SQL-Kenntnisse“ steht, schreibt die nächste es auch, weil deren Fehlen aussehen würde, als suche man jemand Schwächeres. So landen in den Anforderungen an einen Junior Dinge, die er in der Rolle nie anfassen wird.

Der letzte Punkt ist wichtig, wir kommen später darauf zurück. Zuerst zu den Teilen der Liste, die aus gutem Grund dort stehen.

Wofür jede Anforderung wirklich gut ist

Testdesign-Techniken

Die werden gern als Theorie um der Theorie willen behandelt: Äquivalenzklassenbildung lernen, aufsagen, vergessen.

In der Praxis beantwortet die Technik die eine Frage, die dir bei der Arbeit ständig gestellt wird: Warum hast du genau das getestet, und warum reicht das?

Ohne Technik lautet die Antwort: „Na ja, ich habe die Hauptabläufe durchgeklickt.“ Das ist kein Argument – man kann es weder prüfen noch anfechten. Mit Technik wird daraus: „Das Feld akzeptiert 18 bis 65, ich habe je einen Wert aus jeder Klasse getestet plus die Grenzen – sechs Tests statt hundertzwanzig, und hier ist, warum der Rest nichts bringt.“

Der zweite, weniger offensichtliche Punkt: Techniken sind das Werkzeug, um in die verfügbare Zeit zu passen. Alles zu testen ist nie eine Option. Testdesign ist ein Werkzeug, um den Umfang begründet einzugrenzen, kein akademisches Fach.

SQL

Der übliche Einwand: „Wozu braucht ein Tester die Datenbank, ich teste doch die Oberfläche.“

Die Oberfläche zeigt dir, was das Frontend gerendert hat. Sie zeigt dir nicht, was tatsächlich gespeichert wurde.

Der Klassiker: Ein Nutzer speichert sein Profil, die Seite sagt „gespeichert“, du machst weiter. In der Datenbank ist das Feld weiterhin leer, weil das Backend für eine Anfrage, die nichts verändert hat, ein 200 zurückgegeben hat. Eine Woche später findet es ein Kunde.

Der zweite Anwendungsfall kommt sogar noch häufiger vor – Testdaten. Du brauchst einen Nutzer mit abgelaufenem Abo, drei Bestellungen und einer retournierten Position. Über die UI ist das ein halber Tag Klicken. Als Query ist es eine Minute.

Der Umfang, den ein Junior tatsächlich braucht, ist klein: select mit where, Sortierung, ein join über zwei Tabellen, count mit group by. Das ist kein „SQL können“, das sind vier Konstrukte.

API und HTTP

Der Grund hier ist der einfachste von allen. Der Kern der Arbeit eines Junior-QA ist nicht, den Fehler zu finden. Es ist, ihn zu lokalisieren.

„Funktioniert nicht“ ist kein Bugreport. Ein Entwickler verbringt eine Stunde damit herauszufinden, was du in einer Minute hättest klären können: Ist die Anfrage überhaupt rausgegangen, was kam zurück, ist das ein 400 wegen deiner Eingabe oder ein 500 wegen ihres Codes.

Daher kommen die Fragen zu Statuscodes, DevTools und Postman. Das ist keine Trivia-Kenntnis, sondern die Fähigkeit zu sagen, auf welcher Seite das Problem liegt. Ein Tester, der das kann, spart dem Team jede Woche Stunden – genau deshalb wird es schon beim Einstieg abgefragt.

Dazu kommt Funktionalität ganz ohne Oberfläche. Eine Zahlungsanbieter-Integration, ein Webhook von einem externen Dienst, ein Background-Job – die lassen sich nur per Request prüfen.

XSS, Injection und Sicherheitsgrundlagen

Das wirkt wie der am wenigsten juniorgerechte Punkt der Liste. Aber der Grund liegt nicht in der Tiefe, sondern in den Kosten eines übersehenen Fehlers.

Ein übersehener Layout-Bug ist ein Bug. Eine übersehene XSS ist ein Vorfall: Datenleck, Benachrichtigung der Nutzer, manchmal eine Strafe. Der Unterschied liegt nicht in der Schwierigkeit, sondern in den Konsequenzen.

Und die günstigsten Prüfungen kosten nichts. <script>alert(1)</script> in ein Namensfeld einfügen und schauen, ob es ausgeführt wird. Ein einzelnes Anführungszeichen ins Suchfeld setzen und schauen, ob die Query mit einem Datenbankfehler abstürzt. Das ist eine Fünf-Punkte-Checkliste, die zehn Minuten dauert und die billigste Angriffsklasse überhaupt abdeckt.

Niemand erwartet von einem Junior einen Penetrationstest. Man erwartet, dass er am Offensichtlichen nicht vorbeigeht.

Umgebungen und Logs

Fragen zu dev, staging und production sowie dazu, wie man Logs liest, lösen dieselbe Verwunderung aus. Der Grund ist wieder ein praktischer: Die Hälfte aller „Bugs“ sind gar keine Bugs, sondern die falsche Umgebung, ein veralteter Build oder ein Unterschied in der Konfiguration.

Ein Tester, der vor dem Melden prüft, in welchem Build sich der Fehler reproduzieren lässt und was die Logs sagen, erzeugt weniger Rauschen. Und Rauschen im Tracker kostet das Team mehr, als es aussieht.

Und was wirklich überflüssig ist

Jetzt zum ehrlichen Teil.

Einen Junior-Manual-QA nach den Schichten des OSI-Modells zu fragen, nach Replikation in SQL Server oder dem Unterschied zwischen SIP und PRI, ist keine Einschätzung der Job-Reife. Es ist entweder eine irgendwo abgeschriebene Liste oder der Versuch, irgendwie zu filtern, wenn zweihundert Leute sich beworben haben.

Der Test für ein gesundes Interview ist einfach: Bei jeder Frage kann der Interviewer sagen, wie sie im ersten Arbeitsmonat vorkommen wird. „Du wirst Daten in der Datenbank prüfen“ – ja, kann er. „Du wirst Replikation konfigurieren“ – auf einer Junior-Stelle eher nicht.

Wenn die meisten Fragen diesen Test nicht bestehen, sagt das etwas über den Einstellungsprozess des Unternehmens aus, nicht über dich. Das ist ein völlig guter Grund, die Absage nicht zu bereuen.

Was du damit machen kannst

Die Latte sinkt nicht mehr; das alte Verhältnis von Leuten zu offenen Stellen kommt nicht zurück. Aber die Liste dessen, was du wirklich brauchst, ist deutlich kürzer, als es die Stellenanzeigen vermuten lassen.

Das Minimum, mit dem du die meisten Junior-Interviews besteht:

• Testdesign – Äquivalenzklassenbildung, Grenzwerte, Entscheidungstabellen. Mit durchgerechneten Beispielen an konkreten Feldern, nicht mit Definitionen.
• HTTP – Methoden, Statuscode-Klassen, der Network-Tab, die Fähigkeit zu sagen, auf welcher Seite ein Fehler liegt.
• API – Postman, GET und POST, eine Antwort lesen, Dinge prüfen, die die UI nicht zeigt.
• SQL – select, where, order by, join, count mit group by. Vier Konstrukte.
• Sicherheit – eine Fünf-Punkte-Checkliste: XSS in Eingabefeldern, ein Anführungszeichen im Suchfeld, der Datensatz eines anderen Nutzers per ID in der URL, Passwort-Maskierung und eine Fehlermeldung, die nicht verrät, ob ein Login existiert.
• Bugreports – und das Verständnis, dass die Vorbedingungen wichtiger sind als der Screenshot.

Das sind ein paar Wochen konzentrierte Vorbereitung, kein Jahr Studium. Die meisten Absagen passieren nicht, weil der Kandidat davon noch nie gehört hat, sondern weil er es im Modus „davon habe ich gelesen“ kennt statt „ich kann es anwenden und sagen, warum es wichtig ist“.

Noch eine letzte Sache. Jeder Punkt oben lohnt sich, laut sagen zu können. Aufgeschrieben wirkt die eigene Argumentation vollständig. Zum ersten Mal im Interview ausgesprochen, kommt sie in anderer Reihenfolge heraus, und die Hälfte fehlt. Das ist kein Wissensproblem, und Lesen behebt es nicht.

---

Wenn du Material zum Üben suchst: Wir pflegen Fragen für Manual-QA-Interviews mit Musterantworten, getrennt nach Junior und Middle, frei zugänglich.