QA Engineer

Descrizione della posizione

Regara è una piattaforma di intelligence clinica e regolatoria per il settore delle scienze della vita. Aziende di dispositivi medici, farmaceutiche e biotech ci utilizzano per pianificare e preparare ciò che serve per portare un prodotto sul mercato — strategia regolatoria, protocolli clinici, report di studio e dossier di registrazione — su più mercati.

L’IA è il prodotto. Gestiamo una piattaforma di agenti autonomi che ricercano dati in tempo reale, ragionano su di essi e redigono documenti tecnici completi dall’inizio alla fine. Questo rende la qualità un problema davvero difficile. I risultati vengono generati anziché essere fissi, lo stesso input può produrre testi diversi due volte, e il risultato finale è un documento che un cliente presenta a un’autorità regolatoria.

Cosa distingue questo ruolo dalla maggior parte dei lavori di QA. Qui un difetto non è un pulsante disallineato. È un numero sbagliato, un’affermazione non supportata o una citazione la cui fonte non dice ciò per cui è citata. Un documento generato può essere scorrevole, ben formattato e sbagliato — e niente sullo schermo te lo dirà. Individuarli prima del cliente è il lavoro.

Questo è un ruolo interamente dedicato alla qualità. Non ti assumiamo per sviluppare funzionalità tra un ciclo di test e l’altro; ti assumiamo perché il problema di qualità più difficile di questa azienda richiede qualcuno che vi dedichi tutta la propria attenzione. Sarai responsabile di un’area di test dall’inizio alla fine — dai test esplorativi e dai casi che scrivi, attraverso il tracciamento dei difetti, fino alla conferma della correzione in produzione.

Su cosa lavorerai davvero

01 · Test esplorativi e funzionali

Usa il prodotto come farebbe un cliente, poi vai a cercare i punti in cui cede.

• Eseguire test funzionali e di UI/UX su flussi di avvio, viste dei risultati e strumenti di amministrazione.
• Sondare i casi limite — stati vuoti, input sovradimensionati, esecuzioni interrotte, permessi e differenze tra browser e dimensioni dello schermo.
• Testare i flussi di lavoro che i clienti usano davvero, non solo singole schermate isolate.
• Ritestare ogni release e individuare le regressioni.

02 · Progettazione dei test e copertura di regressione

Trasforma ciò che impari in qualcosa di ripetibile che sopravviva alla singola release.

• Scrivere e mantenere casi di test e checklist che coprano i principali flussi utente.
• Essere responsabile della suite di regressione che il team esegue prima di ogni release, mantenendola aggiornata con l’evoluzione del prodotto.
• Mappare la copertura rispetto alla superficie del prodotto e dire chiaramente dove sono le lacune.
• Dare priorità in base al rischio, non a ciò che è facile da testare. Una suite completa sulle parti poco critiche e nulla su quelle critiche è peggio di nessuna suite, perché sembra copertura.

03 · Verifica dei risultati generati

La metà più interessante di questo lavoro, e la parte senza un metodo consolidato.

• Verificare la coerenza interna dei deliverable generati — numeri, rimandi, completezza delle sezioni e formattazione.
• Ricondurre identificativi e riferimenti prodotti da un agente alla fonte ufficiale.
• Segnalare affermazioni non supportate, attribuzioni errate e citazioni il cui contenuto non supporta l’affermazione che le cita. L’integrità delle citazioni è l’attributo di qualità più critico di questo prodotto.
• Valutare i risultati rispetto a esempi di riferimento e riportare gli esiti nella suite di valutazione.
• Progettare approcci di test che funzionino quando il risultato non è deterministico — dove «ha prodotto la stringa attesa?» è la domanda sbagliata.

04 · Segnalazione e triage dei difetti

Un bug report è un deliverable. Scrivilo in modo che qualcuno possa agire senza doverti fare domande.

• Isolare una riproduzione minima e affidabile — non «a volte si rompe».
• Segnalare con passi di riproduzione, risultato atteso rispetto a quello effettivo, ambiente e una gravità che sai motivare.
• Ricondurre un difetto al requisito o al flusso di lavoro che compromette.
• Distinguere un bug del codice da un problema di qualità del modello. Vanno a persone diverse e si correggono in modo diverso; indirizzarli male fa perdere una settimana a tutti.
• Seguire ciascuno fino alla verifica della correzione.

05 · Verifica delle release e segnale di qualità

Qualcuno deve poter dire se una release è sicura, e avere ragione.

• Eseguire la verifica delle release e dare una valutazione chiara e basata su evidenze sulla prontezza di una build.
• Monitorare nel tempo il segnale di qualità — andamento dei difetti, tasso di fuga e punti del prodotto in cui i problemi continuano a nascere.
• Riferire per iscritto all’engineering lo stato della qualità, comprese le parti che nessuno vuole sentire.
• Dare l’allarme presto quando una release sta andando male. Un avviso tardivo è poco meglio di nessun avviso.

06 · Automazione dei test

Trasforma i controlli manuali in controlli automatici — dove il ritorno è reale.

• Estendere la copertura del backend con pytest e quella del frontend con Vitest e React Testing Library.
• Scrivere test end-to-end a livello di browser per i flussi con più traffico.
• Mantenere le suite collegate a GitHub Actions, così che i fallimenti emergano nella pull request anziché dopo il merge.
• Automatizzare con giudizio. Una suite fragile di cui nessuno si fida costa più del controllo manuale che ha sostituito.

Il nostro 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
• IA — API di LLM all’avanguardia (Claude), server di strumenti MCP, RAG, harness di valutazione e valutatori con output di riferimento
• Infrastruttura — AWS (ECS/EC2, ECR, SQS, S3), Docker, GitHub Actions

Non ci aspettiamo che tu conosca tutto. La maggior parte dei test si svolge sull’applicazione più che sul codice — ma è questo che leggerai quando seguirai un bug fino all’origine, e che scriverai quando estenderai le suite automatizzate.

Requisiti

Requisiti richiesti

• Circa 2–5 anni in un ruolo di QA, qualità del software o test engineering, testando un prodotto reale con utenti reali.
• Laurea in Informatica, Ingegneria Informatica o ambito affine — oppure esperienza pratica equivalente.
• Dimestichezza nel leggere e scrivere codice in almeno un linguaggio. Python o TypeScript sono i più vicini al nostro stack, ma Java, C++ o altri vanno benissimo.
• Attenzione al dettaglio che individua il valore sottilmente sbagliato, non solo la pagina che non si carica.
• Scrittura tecnica chiara. Leggeremo i tuoi bug report più del tuo codice.
• Capacità di leggere una fonte primaria — una specifica, una norma, un contratto API — e verificare un’implementazione esattamente rispetto a ciò che dice.
• Metodo nell’ambiguità. Riduci una segnalazione vaga a una riproduzione minima invece di inoltrarla così com’è.
• Esperienza pratica con almeno un framework di test — pytest, Vitest, Playwright, Selenium o simili.
• Dimestichezza con Git e i flussi di lavoro basati su pull request.
• Disponibilità a bloccare una release. Questo ruolo a volte deve dire che una build non è pronta mentre altri la aspettano. Dirlo è il lavoro.
• Disponibilità a lavorare in sede a Las Vegas a tempo pieno e autorizzazione a lavorare negli Stati Uniti.

Requisiti preferenziali

• Esperienza nel testare output generati da IA o LLM, o nel creare ed eseguire harness di valutazione.
• Esperienza in settori regolamentati — dispositivi medici, farmaceutico, ricerca clinica — oppure con 21 CFR Part 11, GxP o convalida dei sistemi computerizzati.
• Test delle API e SQL a un livello sufficiente per verificare i dati direttamente e non solo tramite l’interfaccia.
• Esperienza di CI/CD, in particolare con GitHub Actions.
• Test di accessibilità, oppure test di prestazioni e di carico.
• Esperienza nell’introdurre un processo di test dove non esisteva.
• Esperienza in startup, inclusa la capacità di operare prima che il processo esista.

Come lavoriamo

• Nulla viene rilasciato sulla base di un solo esempio convincente. Ogni modifica a prompt, retrieval o strumenti viene valutata rispetto a una suite di regressione e a un insieme di output valutati prima di arrivare al cliente. Iteriamo sui numeri.
• Ciclo rapido verso la produzione. Testerai su staging già dalla prima settimana, e i bug che segnali vengono corretti abbastanza in fretta da poter verificare tu stesso la correzione.
• Sei responsabile di un’area di test dall’inizio alla fine. Dai test esplorativi e dai casi che scrivi, attraverso l’automazione e il tracciamento dei difetti, fino alla conferma della correzione in produzione. Nessuno ti consegna uno script da eseguire tenendosi la parte di pensiero.
• Team piccolo, collaborazione diretta. Lavori a fianco del team di engineering fondatore, con code review su ogni pull request che apri.
• Costruiamo sulla frontiera. Seguiamo i nuovi rilasci di modelli, le capacità di contesto e caching e gli strumenti per agenti man mano che arrivano, e ricostruiamo attorno a essi quando sono migliori. Ciò che impari qui è attuale.

Come si misura il successo

• I difetti vengono trovati in staging, non dai clienti — e il tasso di fuga è in calo.
• Le citazioni inventate, errate o non supportate vengono individuate internamente prima che un cliente le veda.
• Un’esecuzione di regressione verde significa davvero qualcosa, perché la suite copre ciò che conta e non è instabile.
• Si agisce sui bug report senza bisogno di domande di chiarimento.
• Le lacune di copertura sono note e dichiarate in anticipo, anziché scoperte a seguito di un incidente.
• I problemi di qualità del modello e i difetti del codice arrivano alle persone giuste al primo tentativo.
• Le decisioni di rilascio si basano su evidenze, e l’engineering si fida della tua valutazione.

Perché esiste questo ruolo

Il QA tradizionale presuppone una risposta corretta rispetto a cui verificare. Qui il sistema scrive ogni volta qualcosa di nuovo, e la modalità di errore è un documento che si legge perfettamente e contiene un’affermazione che la sua stessa citazione non supporta. Non è un problema che si risolve aggiungendo asserzioni — serve qualcuno che legga i risultati come li leggerebbe un’autorità regolatoria. Questo è il ruolo.