QA Engineer

Die Position im Überblick

Regara ist eine Plattform für klinische und regulatorische Intelligenz für die Life-Sciences-Branche. Medizintechnik-, Pharma- und Biotech-Unternehmen nutzen uns, um alles zu planen und vorzubereiten, was sie für die Markteinführung eines Produkts benötigen — regulatorische Strategie, klinische Prüfpläne, Studienberichte und Zulassungsdossiers — über mehrere Märkte hinweg.

KI ist das Produkt. Wir betreiben eine Plattform autonomer Agenten, die Live-Daten recherchieren, darüber schlussfolgern und vollständige technische Dokumente von Anfang bis Ende erstellen. Das macht Qualität zu einem wirklich schwierigen Problem. Die Ergebnisse werden generiert statt fest vorgegeben, dieselbe Eingabe kann zweimal unterschiedlichen Text erzeugen, und am Ende steht ein Dokument, das ein Kunde bei einer Behörde einreicht.

Was diese Rolle von den meisten QA-Jobs unterscheidet. Ein Fehler ist hier kein verrutschter Button. Es ist eine falsche Zahl, eine unbelegte Aussage oder ein Zitat, dessen Quelle nicht sagt, wofür sie zitiert wird. Ein generiertes Dokument kann flüssig formuliert, sauber formatiert und falsch sein — und nichts auf dem Bildschirm verrät es Ihnen. Solche Fehler zu finden, bevor ein Kunde es tut, ist der Job.

Dies ist eine reine Qualitätsrolle. Sie werden nicht eingestellt, um zwischen Testzyklen Produktfeatures zu entwickeln, sondern weil das schwierigste Qualitätsproblem dieses Unternehmens jemanden braucht, der sich ihm voll widmet. Sie verantworten einen Testbereich von Anfang bis Ende — von explorativen Durchläufen und selbst geschriebenen Testfällen über die Fehlerverfolgung bis zur Bestätigung der Korrektur in Produktion.

Woran Sie tatsächlich arbeiten

01 · Exploratives und funktionales Testen

Nutzen Sie das Produkt wie ein Kunde — und suchen Sie dann die Stellen, an denen es nachgibt.

• Funktionale und UI/UX-Tests über Dispatch-Flows, Ergebnisansichten und Admin-Tools durchführen.
• Grenzfälle ausloten — leere Zustände, übergroße Eingaben, unterbrochene Durchläufe, Berechtigungen sowie Browser- und Viewport-Unterschiede.
• Die Workflows testen, die Kunden tatsächlich nutzen, nicht nur einzelne Bildschirme isoliert.
• Jedes Release erneut testen und Regressionen aufdecken.

02 · Testdesign und Regressionsabdeckung

Machen Sie aus Ihren Erkenntnissen etwas Wiederholbares, das jedes einzelne Release überdauert.

• Testfälle und Checklisten für zentrale Nutzer-Workflows schreiben und pflegen.
• Die Regressionssuite verantworten, die das Team vor einem Release ausführt, und sie aktuell halten, während sich das Produkt verändert.
• Die Abdeckung gegen die Produktoberfläche abbilden und klar benennen, wo die Lücken sind.
• Nach Risiko priorisieren, nicht danach, was leicht zu testen ist. Eine gründliche Suite für den unkritischen Bereich und nichts für den kritischen ist schlimmer als gar keine Suite, weil sie wie Abdeckung aussieht.

03 · Generierte Ergebnisse verifizieren

Die spannendere Hälfte dieses Jobs — und der Teil, für den es kein etabliertes Vorgehen gibt.

• Generierte Ergebnisse auf innere Konsistenz prüfen — Zahlen, Querverweise, Vollständigkeit der Abschnitte und Formatierung.
• Von einem Agenten erzeugte Kennungen und Referenzen gegen die maßgebliche Quelle abgleichen.
• Unbelegte Aussagen, falsche Zuordnungen und Zitate markieren, deren Inhalt die zitierende Aussage nicht stützt. Zitatintegrität ist das kritischste Qualitätsmerkmal dieses Produkts.
• Ergebnisse gegen Referenzbeispiele (Golden Examples) bewerten und die Resultate in die Eval-Suite zurückführen.
• Testansätze entwickeln, die bei nichtdeterministischen Ergebnissen funktionieren — wo „Hat es den erwarteten String erzeugt?“ die falsche Frage ist.

04 · Fehlerberichte und Triage

Ein Bug-Report ist ein Arbeitsergebnis. Schreiben Sie ihn so, dass jemand ohne Rückfrage handeln kann.

• Eine minimale, zuverlässige Reproduktion isolieren — nicht „es bricht manchmal“.
• Mit Reproduktionsschritten, erwartetem gegenüber tatsächlichem Verhalten, Umgebung und einer vertretbaren Schweregrad-Einstufung berichten.
• Einen Fehler auf die Anforderung oder den Workflow zurückführen, den er verletzt.
• Einen Code-Bug von einem Problem der Modellqualität unterscheiden. Sie gehen an unterschiedliche Personen und werden unterschiedlich behoben — eine Fehlzuordnung kostet alle eine Woche.
• Jeden Fehler bis zur Verifizierung der Korrektur verfolgen.

05 · Release-Verifizierung und Qualitätssignal

Jemand muss sagen können, ob ein Release sicher ist — und damit richtigliegen.

• Die Release-Verifizierung durchführen und eine klare, belegte Einschätzung geben, ob ein Build bereit ist.
• Das Qualitätssignal über die Zeit verfolgen — Fehlertrends, Escape-Rate und wo im Produkt Probleme immer wieder entstehen.
• Den Qualitätsstatus schriftlich an das Engineering berichten, einschließlich der Teile, die niemand hören will.
• Früh Alarm schlagen, wenn sich ein Release schlecht entwickelt. Eine späte Warnung ist kaum besser als keine.

06 · Testautomatisierung

Überführen Sie manuelle Prüfungen in automatisierte — dort, wo es sich wirklich lohnt.

• Die Backend-Abdeckung mit pytest und die Frontend-Abdeckung mit Vitest und React Testing Library erweitern.
• Browserbasierte End-to-End-Tests für die meistgenutzten Workflows schreiben.
• Suites in GitHub Actions eingebunden halten, damit Fehler im Pull Request sichtbar werden und nicht erst nach dem Merge.
• Mit Augenmaß automatisieren. Eine fragile Suite, der niemand vertraut, kostet mehr als der manuelle Durchlauf, den sie ersetzt hat.

Unser Stack

• Backend — Python 3.12, FastAPI, SQLAlchemy 2.0, Pydantic v2, Postgres / SQLite, pytest
• Frontend — React 19, TypeScript (strict), Vite, TanStack Router + Query, Tailwind, shadcn/ui, Vitest + RTL
• KI — Frontier-LLM-APIs (Claude), MCP-Toolserver, RAG, Eval-Harnesses und Golden-Output-Grader
• Infrastruktur — AWS (ECS/EC2, ECR, SQS, S3), Docker, GitHub Actions

Sie müssen nicht alles davon kennen. Die meisten Tests laufen gegen die Anwendung, nicht gegen den Code — aber das ist es, was Sie lesen, wenn Sie einem Bug bis zur Ursache nachgehen, und was Sie schreiben, wenn Sie die automatisierten Suites erweitern.

Qualifikationen

Voraussetzungen

• Etwa 2–5 Jahre in einer Rolle in QA, Softwarequalität oder Test Engineering, mit Tests an einem echten Produkt mit echten Nutzern.
• Abschluss in Informatik, Technischer Informatik oder einem verwandten Fach — oder gleichwertige praktische Erfahrung.
• Sicherer Umgang beim Lesen und Schreiben von Code in mindestens einer Sprache. Python oder TypeScript liegen am nächsten an unserem Stack, aber Java, C++ oder anderes ist ebenfalls in Ordnung.
• Ein Blick fürs Detail, der den subtil falschen Wert findet, nicht nur die Seite, die nicht lädt.
• Klares technisches Schreiben. Wir werden Ihre Bug-Reports öfter lesen als Ihren Code.
• Die Fähigkeit, eine Primärquelle — eine Spezifikation, eine Norm, einen API-Vertrag — zu lesen und eine Implementierung exakt daran zu prüfen.
• Methodisches Vorgehen bei Unklarheit. Sie grenzen eine vage Beschwerde auf eine minimale Reproduktion ein, statt sie unverändert weiterzureichen.
• Praktische Erfahrung mit mindestens einem Test-Framework — pytest, Vitest, Playwright, Selenium oder ähnlich.
• Sicherer Umgang mit Git und Pull-Request-Workflows.
• Die Bereitschaft, ein Release anzuhalten. Diese Rolle muss manchmal sagen, dass ein Build nicht bereit ist, während andere darauf warten. Genau das ist der Job.
• Die Möglichkeit, Vollzeit vor Ort in Las Vegas zu arbeiten, und eine Arbeitserlaubnis für die USA.

Wünschenswert

• Erfahrung im Testen von KI- bzw. LLM-generierten Ergebnissen oder im Aufbau und Betrieb von Eval-Harnesses.
• Erfahrung in regulierten Branchen — Medizintechnik, Pharma, klinische Forschung — oder mit 21 CFR Part 11, GxP oder Computersystemvalidierung.
• API-Tests und SQL-Kenntnisse, die ausreichen, um Daten direkt und nicht nur über die Oberfläche zu prüfen.
• CI/CD-Erfahrung, insbesondere mit GitHub Actions.
• Barrierefreiheitstests oder Performance- und Lasttests.
• Erfahrung im Aufbau eines Testprozesses dort, wo es noch keinen gab.
• Startup-Erfahrung, einschließlich der Fähigkeit, zu arbeiten, bevor der Prozess existiert.

Wie wir arbeiten

• Nichts wird auf Basis eines einzigen gut aussehenden Beispiels ausgeliefert. Jede Änderung an Prompts, Retrieval oder Tools wird gegen eine Regressionssuite und eine Reihe bewerteter Ergebnisse geprüft, bevor sie einen Kunden erreicht. Wir iterieren anhand von Zahlen.
• Schneller Weg in die Produktion. Sie testen schon in Ihrer ersten Woche gegen Staging, und die Bugs, die Sie melden, werden so schnell behoben, dass Sie die Korrektur selbst verifizieren.
• Sie verantworten einen Testbereich von Anfang bis Ende. Von explorativen Durchläufen und Ihren eigenen Testfällen über Automatisierung und Fehlerverfolgung bis zur Bestätigung der Korrektur in Produktion. Niemand drückt Ihnen ein Skript zum Abarbeiten in die Hand und nimmt Ihnen das Denken ab.
• Kleines Team, direkte Zusammenarbeit. Sie arbeiten mit dem Gründungs-Engineering-Team zusammen, mit Code-Review für jeden Pull Request, den Sie eröffnen.
• Wir bauen an der vordersten Front. Wir verfolgen neue Modellversionen, Kontext- und Caching-Fähigkeiten und Agent-Tooling, sobald sie erscheinen, und bauen darauf um, wenn sie besser sind. Was Sie hier lernen, ist aktuell.

Woran wir Erfolg messen

• Fehler werden in Staging gefunden, nicht von Kunden — und die Escape-Rate sinkt.
• Erfundene, falsch zugeordnete oder unbelegte Zitate werden intern gefunden, bevor ein Kunde sie je sieht.
• Ein grüner Regressionslauf bedeutet tatsächlich etwas, weil die Suite das Wesentliche abdeckt und nicht flaky ist.
• Auf Bug-Reports wird ohne Rückfrage gehandelt.
• Abdeckungslücken sind im Voraus bekannt und benannt, statt durch einen Vorfall entdeckt zu werden.
• Probleme der Modellqualität und Code-Fehler landen gleich beim ersten Mal bei den richtigen Personen.
• Release-Entscheidungen sind belegt, und das Engineering vertraut Ihrer Einschätzung.

Warum es diese Rolle gibt

Klassische QA setzt eine korrekte Antwort voraus, gegen die man prüfen kann. Hier schreibt das System jedes Mal etwas Neues, und der Fehlerfall ist ein Dokument, das sich einwandfrei liest und eine Aussage enthält, die das eigene Zitat nicht stützt. Dieses Problem löst man nicht mit zusätzlichen Assertions — es braucht jemanden, der die Ergebnisse so liest, wie eine Behörde es tun würde. Genau das ist diese Rolle.