Engenheiro de QA

Resumo da vaga

A Regara é uma plataforma de inteligência clínica e regulatória para o setor de ciências da vida. Empresas de dispositivos médicos, farmacêuticas e de biotecnologia nos usam para planejar e preparar o que precisam para levar um produto ao mercado — estratégia regulatória, protocolos clínicos, relatórios de estudo e dossiês de submissão — em vários mercados.

A IA é o produto. Operamos uma plataforma de agentes autônomos que pesquisam dados em tempo real, raciocinam sobre eles e redigem documentos técnicos completos de ponta a ponta. Isso torna a qualidade um problema realmente difícil. O resultado é gerado, e não fixo; a mesma entrada pode produzir textos diferentes duas vezes; e o produto final é um documento que o cliente submete a uma autoridade regulatória.

O que diferencia esta vaga da maioria dos trabalhos de QA. Aqui, um defeito não é um botão desalinhado. É um número errado, uma afirmação sem respaldo ou uma citação cuja fonte não diz aquilo para o qual é citada. Um documento gerado pode ser fluente, bem formatado e errado — e nada na tela vai avisar você. Encontrar isso antes do cliente é o trabalho.

Esta é uma função dedicada exclusivamente à qualidade. Você não está sendo contratado para desenvolver funcionalidades entre ciclos de teste; está sendo contratado porque o problema de qualidade mais difícil desta empresa precisa de alguém com atenção total a ele. Você será responsável por uma área de testes de ponta a ponta — dos testes exploratórios e dos casos que escrever, passando pelo acompanhamento dos defeitos, até a confirmação da correção em produção.

No que você vai trabalhar de fato

01 · Testes exploratórios e funcionais

Use o produto como um cliente usaria e depois vá procurar os pontos em que ele cede.

• Executar testes funcionais e de UI/UX em fluxos de execução, telas de resultados e ferramentas de administração.
• Explorar os limites — estados vazios, entradas muito grandes, execuções interrompidas, permissões e diferenças entre navegadores e tamanhos de tela.
• Testar os fluxos que os clientes realmente usam, não apenas telas isoladas.
• Retestar cada versão e identificar o que regrediu.

02 · Desenho de testes e cobertura de regressão

Transforme o que você aprende em algo repetível que dure além de uma única versão.

• Escrever e manter casos de teste e checklists que cubram os principais fluxos de usuário.
• Ser responsável pela suíte de regressão que o time executa antes de cada versão e mantê-la atualizada à medida que o produto muda.
• Mapear a cobertura em relação à superfície do produto e dizer claramente onde estão as lacunas.
• Priorizar por risco, não pelo que é fácil de testar. Uma suíte completa sobre o que é pouco crítico e nada sobre o que é crítico é pior do que nenhuma suíte, porque parece cobertura.

03 · Verificação de resultados gerados

A metade mais interessante deste trabalho, e a parte sem um método consolidado.

• Verificar a consistência interna dos entregáveis gerados — números, referências cruzadas, completude das seções e formatação.
• Conferir os identificadores e referências que um agente produz com a fonte oficial.
• Sinalizar afirmações sem respaldo, atribuições incorretas e citações cujo conteúdo não sustenta a afirmação que as cita. A integridade das citações é o atributo de qualidade mais crítico deste produto.
• Avaliar os resultados com base em exemplos de referência e realimentar a suíte de avaliação com os resultados.
• Desenhar abordagens de teste que funcionem quando o resultado não é determinístico — em que “ele produziu a string esperada?” é a pergunta errada.

04 · Registro e triagem de defeitos

Um relatório de bug é um entregável. Escreva-o para que alguém possa agir sem precisar fazer perguntas a você.

• Isolar uma reprodução mínima e confiável — e não “às vezes quebra”.
• Reportar com passos de reprodução, resultado esperado versus obtido, ambiente e uma severidade que você consiga defender.
• Rastrear um defeito até o requisito ou fluxo que ele compromete.
• Distinguir um bug de código de um problema de qualidade do modelo. Eles vão para pessoas diferentes e são corrigidos de formas diferentes; encaminhar errado faz todo mundo perder a semana.
• Acompanhar cada um até a verificação da correção.

05 · Verificação de versões e sinal de qualidade

Alguém precisa ser capaz de dizer se uma versão é segura — e acertar.

• Executar a verificação de versões e dar uma avaliação clara e baseada em evidências sobre se um build está pronto.
• Acompanhar o sinal de qualidade ao longo do tempo — tendências de defeitos, taxa de escape e onde no produto os problemas continuam surgindo.
• Reportar por escrito o status da qualidade para a engenharia, incluindo as partes que ninguém quer ouvir.
• Dar o alerta cedo quando uma versão está indo mal. Um aviso tardio é pouco melhor do que nenhum.

06 · Automação de testes

Transforme as verificações manuais em verificações automáticas — onde o retorno for real.

• Ampliar a cobertura do backend com pytest e a do frontend com Vitest e React Testing Library.
• Escrever testes end-to-end em nível de navegador para os fluxos de maior tráfego.
• Manter as suítes integradas ao GitHub Actions para que as falhas apareçam no pull request, e não depois do merge.
• Automatizar com critério. Uma suíte frágil em que ninguém confia custa mais do que a verificação manual que substituiu.

Nosso 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 — APIs de LLM de fronteira (Claude), servidores de ferramentas MCP, RAG, harnesses de avaliação e avaliadores com resultados de referência
• Infraestrutura — AWS (ECS/EC2, ECR, SQS, S3), Docker, GitHub Actions

Não esperamos que você conheça tudo isso. A maior parte dos seus testes é feita na aplicação, e não no código — mas é isso que você vai ler ao rastrear um bug até a origem, e o que vai escrever ao ampliar as suítes automatizadas.

Qualificações

Requisitos

• Cerca de 2–5 anos em uma função de QA, qualidade de software ou engenharia de testes, testando um produto real com usuários reais.
• Graduação em Ciência da Computação, Engenharia da Computação ou área relacionada — ou experiência prática equivalente.
• Facilidade para ler e escrever código em pelo menos uma linguagem. Python ou TypeScript são as mais próximas do nosso stack, mas Java, C++ ou qualquer outra também servem.
• Atenção aos detalhes que pegue o valor sutilmente errado, e não só a página que não carrega.
• Escrita técnica clara. Vamos ler seus relatórios de bug mais do que o seu código.
• Capacidade de ler uma fonte primária — uma especificação, uma norma, um contrato de API — e verificar uma implementação exatamente em relação ao que ela diz.
• Método diante da ambiguidade. Você reduz uma reclamação vaga a uma reprodução mínima em vez de escalá-la do jeito que chegou.
• Experiência prática com pelo menos um framework de testes — pytest, Vitest, Playwright, Selenium ou similar.
• Familiaridade com Git e fluxos de pull request.
• Disposição para segurar uma versão. Esta função às vezes precisa dizer que um build não está pronto enquanto há gente esperando. Dizer isso é o trabalho.
• Disponibilidade para trabalhar presencialmente em Las Vegas em período integral e autorização para trabalhar nos Estados Unidos.

Diferenciais

• Experiência testando resultados gerados por IA ou LLM, ou criando e executando harnesses de avaliação.
• Experiência em setores regulados — dispositivos médicos, farmacêutico, pesquisa clínica — ou com 21 CFR Part 11, GxP ou validação de sistemas computadorizados.
• Testes de API e SQL com fluência suficiente para verificar dados diretamente, e não só pela interface.
• Experiência com CI/CD, especialmente GitHub Actions.
• Testes de acessibilidade, ou testes de desempenho e carga.
• Experiência implantando um processo de testes onde não havia nenhum.
• Experiência em startups, incluindo conforto para atuar antes que o processo exista.

Como construímos

• Nada é lançado com base em um único exemplo bonito. Toda mudança de prompt, recuperação ou ferramenta é avaliada contra uma suíte de regressão e um conjunto de resultados avaliados antes de chegar ao cliente. Iteramos com base em números.
• Ciclo rápido até a produção. Você vai testar em staging já na primeira semana, e os bugs que você registrar são corrigidos rápido o suficiente para que você mesmo verifique a correção.
• Você é responsável por uma área de testes de ponta a ponta. Dos testes exploratórios e dos casos que escrever, passando pela automação e pelo acompanhamento dos defeitos, até a confirmação da correção em produção. Ninguém entrega um roteiro para você executar e fica com a parte de pensar.
• Time pequeno, colaboração direta. Você trabalha ao lado do time fundador de engenharia, com code review em cada pull request que abrir.
• Construímos na fronteira. Acompanhamos novos lançamentos de modelos, capacidades de contexto e cache e ferramentas de agentes assim que surgem, e reconstruímos em torno deles quando são melhores. O que você aprende aqui é atual.

Como será o sucesso

• Os defeitos são encontrados em staging, não pelos clientes — e a taxa de escape está caindo.
• Citações inventadas, incorretas ou sem respaldo são identificadas internamente antes que um cliente as veja.
• Uma execução de regressão verde realmente significa algo, porque a suíte cobre o que importa e não é instável.
• Os relatórios de bug são resolvidos sem perguntas adicionais.
• As lacunas de cobertura são conhecidas e comunicadas com antecedência, em vez de descobertas por um incidente.
• Problemas de qualidade do modelo e defeitos de código chegam às pessoas certas na primeira vez.
• As decisões de lançamento têm evidências por trás, e a engenharia confia na sua avaliação.

Por que esta função existe

O QA tradicional pressupõe uma resposta correta contra a qual se pode verificar. Aqui, o sistema escreve algo novo a cada vez, e o modo de falha é um documento que se lê perfeitamente e contém uma afirmação que a sua própria citação não sustenta. Esse não é um problema que se resolve adicionando asserções — é preciso alguém que leia o resultado como um órgão regulador leria. Essa é esta função.