Ingeniero de QA

Resumen del puesto

Regara es una plataforma de inteligencia clínica y regulatoria para la industria de ciencias de la vida. Empresas de dispositivos médicos, farmacéuticas y de biotecnología nos utilizan para planificar y preparar lo que necesitan para llevar un producto al mercado — estrategia regulatoria, protocolos clínicos, informes de estudios y expedientes de solicitud — en múltiples mercados.

La IA es el producto. Operamos una plataforma de agentes autónomos que investigan datos en tiempo real, razonan sobre ellos y redactan documentos técnicos completos de principio a fin. Eso convierte la calidad en un problema realmente difícil. Los resultados se generan en lugar de ser fijos, la misma entrada puede producir textos distintos dos veces, y el resultado final es un documento que un cliente presenta ante un organismo regulador.

Qué diferencia este puesto de la mayoría de los trabajos de QA. Aquí un defecto no es un botón desalineado. Es un número incorrecto, una afirmación sin respaldo o una cita cuya fuente no dice lo que se le atribuye. Un documento generado puede ser fluido, estar bien formateado y ser incorrecto — y nada en la pantalla se lo indicará. Detectar eso antes que el cliente es el trabajo.

Este es un puesto dedicado exclusivamente a la calidad. No le contratamos para desarrollar funcionalidades entre ciclos de pruebas; le contratamos porque el problema de calidad más difícil de esta empresa necesita a alguien con toda su atención puesta en él. Será responsable de un ámbito de pruebas de principio a fin — desde las pruebas exploratorias y los casos que redacte, pasando por el seguimiento de defectos, hasta confirmar la corrección en producción.

En qué trabajará realmente

01 · Pruebas exploratorias y funcionales

Use el producto como lo haría un cliente y luego busque los puntos donde falla.

• Realizar pruebas funcionales y de UI/UX en los flujos de ejecución, las vistas de resultados y las herramientas de administración.
• Explorar los límites — estados vacíos, entradas de gran tamaño, ejecuciones interrumpidas, permisos y diferencias entre navegadores y tamaños de pantalla.
• Probar los flujos de trabajo que los clientes realmente utilizan, no solo pantallas aisladas.
• Volver a probar cada versión y detectar las regresiones.

02 · Diseño de pruebas y cobertura de regresión

Convierta lo que aprende en algo repetible que perdure más allá de una sola versión.

• Redactar y mantener casos de prueba y listas de verificación que cubran los flujos de trabajo principales.
• Ser responsable de la suite de regresión que el equipo ejecuta antes de cada versión y mantenerla al día a medida que cambia el producto.
• Mapear la cobertura frente a la superficie del producto y señalar con claridad dónde están las carencias.
• Priorizar por riesgo, no por lo que es fácil de probar. Una suite exhaustiva sobre lo poco crítico y nada sobre lo crítico es peor que no tener suite, porque aparenta cobertura.

03 · Verificación de resultados generados

La mitad más interesante de este trabajo, y la parte sin un método establecido.

• Revisar la coherencia interna de los entregables generados — cifras, referencias cruzadas, integridad de las secciones y formato.
• Cotejar los identificadores y referencias que produce un agente con la fuente oficial.
• Señalar afirmaciones sin respaldo, atribuciones erróneas y citas cuyo contenido no respalda la afirmación que las cita. La integridad de las citas es el atributo de calidad más crítico de este producto.
• Evaluar los resultados frente a ejemplos de referencia e incorporar los hallazgos a la suite de evaluación.
• Diseñar enfoques de prueba que funcionen cuando el resultado no es determinista — donde «¿produjo la cadena esperada?» es la pregunta equivocada.

04 · Reporte y triaje de defectos

Un reporte de error es un entregable. Redáctelo para que alguien pueda actuar sin tener que hacerle preguntas.

• Aislar una reproducción mínima y fiable — no «a veces falla».
• Reportar con pasos de reproducción, resultado esperado frente al real, entorno y una severidad que pueda justificar.
• Rastrear un defecto hasta el requisito o flujo de trabajo que incumple.
• Distinguir un error de código de un problema de calidad del modelo. Van a personas distintas y se corrigen de forma distinta; enviarlos al lugar equivocado le hace perder la semana a todo el mundo.
• Dar seguimiento a cada uno hasta verificar la corrección.

05 · Verificación de versiones y señal de calidad

Alguien tiene que poder decir si una versión es segura, y acertar.

• Realizar la verificación de versiones y dar una valoración clara y respaldada por evidencia sobre si una compilación está lista.
• Seguir la señal de calidad en el tiempo — tendencias de defectos, tasa de escape y en qué parte del producto se originan los problemas una y otra vez.
• Informar por escrito al equipo de ingeniería sobre el estado de la calidad, incluidas las partes que nadie quiere oír.
• Dar la alarma pronto cuando una versión va por mal camino. Un aviso tardío apenas es mejor que ninguno.

06 · Automatización de pruebas

Convierta las comprobaciones manuales en comprobaciones automáticas — allí donde el beneficio sea real.

• Ampliar la cobertura del backend con pytest y la del frontend con Vitest y React Testing Library.
• Escribir pruebas end-to-end a nivel de navegador para los flujos de trabajo de mayor tráfico.
• Mantener las suites integradas en GitHub Actions para que los fallos aparezcan en el pull request y no después del merge.
• Automatizar con criterio. Una suite frágil en la que nadie confía cuesta más que la revisión manual que sustituyó.

Nuestro 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 frontera (Claude), servidores de herramientas MCP, RAG, arneses de evaluación y evaluadores con resultados de referencia
• Infraestructura — AWS (ECS/EC2, ECR, SQS, S3), Docker, GitHub Actions

No se espera que lo conozca todo. La mayoría de sus pruebas se realizan sobre la aplicación y no sobre el código — pero esto es lo que leerá cuando rastree un error hasta su origen, y lo que escribirá cuando amplíe las suites automatizadas.

Requisitos

Imprescindibles

• Aproximadamente 2–5 años en un puesto de QA, calidad de software o ingeniería de pruebas, probando un producto real con usuarios reales.
• Titulación en Informática, Ingeniería Informática o un campo relacionado — o experiencia práctica equivalente.
• Soltura para leer y escribir código en al menos un lenguaje. Python o TypeScript le acercan más a nuestro stack, pero Java, C++ o cualquier otro es válido.
• Atención al detalle que detecte el valor sutilmente incorrecto, no solo la página que no carga.
• Redacción técnica clara. Leeremos sus reportes de errores más que su código.
• Capacidad para leer una fuente primaria — una especificación, una norma, un contrato de API — y comprobar una implementación exactamente contra lo que dice.
• Método ante la ambigüedad. Convierte una queja vaga en una reproducción mínima en lugar de escalarla tal cual.
• Experiencia práctica con al menos un framework de pruebas — pytest, Vitest, Playwright, Selenium o similar.
• Soltura con Git y los flujos de trabajo con pull requests.
• Disposición a detener una versión. Este puesto a veces tiene que decir que una compilación no está lista mientras otros esperan. Decirlo es el trabajo.
• Disponibilidad para trabajar de forma presencial en Las Vegas a jornada completa y autorización para trabajar en Estados Unidos.

Deseables

• Experiencia probando resultados generados por IA o LLM, o creando y ejecutando arneses de evaluación.
• Experiencia en sectores regulados — dispositivos médicos, farmacéutico, investigación clínica — o con 21 CFR Part 11, GxP o validación de sistemas informáticos.
• Pruebas de API y SQL con soltura suficiente para verificar datos directamente y no solo a través de la interfaz.
• Experiencia en CI/CD, en particular con GitHub Actions.
• Pruebas de accesibilidad, o de rendimiento y carga.
• Experiencia implantando un proceso de pruebas donde no existía.
• Experiencia en startups, incluida la comodidad de trabajar antes de que exista el proceso.

Cómo trabajamos

• Nada se publica con base en un solo ejemplo que se ve bien. Cada cambio de prompt, de recuperación o de herramienta se evalúa contra una suite de regresión y un conjunto de resultados calificados antes de llegar a un cliente. Iteramos con números.
• Ciclo rápido hasta producción. Estará probando en staging desde su primera semana, y los errores que reporte se corrigen tan rápido que usted mismo verificará la corrección.
• Es responsable de un ámbito de pruebas de principio a fin. Desde las pruebas exploratorias y los casos que redacte, pasando por la automatización y el seguimiento de defectos, hasta confirmar la corrección en producción. Nadie le entrega un guion para ejecutar y se queda con la parte de pensar.
• Equipo pequeño, colaboración directa. Trabajará junto al equipo fundador de ingeniería, con revisión de código en cada pull request que abra.
• Construimos en la frontera. Seguimos los nuevos lanzamientos de modelos, las capacidades de contexto y caché y las herramientas de agentes a medida que aparecen, y reconstruimos en torno a ellos cuando son mejores. Lo que aprenda aquí está al día.

Cómo se mide el éxito

• Los defectos se encuentran en staging, no los encuentran los clientes — y la tasa de escape va a la baja.
• Las citas inventadas, mal atribuidas o sin respaldo se detectan internamente antes de que un cliente llegue a verlas.
• Una ejecución de regresión en verde significa algo de verdad, porque la suite cubre lo importante y no es inestable.
• Se actúa sobre los reportes de errores sin necesidad de preguntas adicionales.
• Las carencias de cobertura se conocen y se declaran de antemano, en lugar de descubrirse por un incidente.
• Los problemas de calidad del modelo y los defectos de código llegan a las personas adecuadas a la primera.
• Las decisiones de publicación se basan en evidencia, y el equipo de ingeniería confía en su criterio.

Por qué existe este puesto

El QA tradicional supone una respuesta correcta contra la que se puede comprobar. Aquí el sistema escribe algo nuevo cada vez, y el modo de fallo es un documento que se lee perfectamente y contiene una afirmación que su propia cita no respalda. No es un problema que se resuelva añadiendo aserciones — necesita a alguien que lea los resultados como lo haría un regulador. Ese es este puesto.