La mejor prueba de QA para ingenieras de automatización: cómo construir tu evaluación

Qué significa «mejor» en evaluación QA

No hay un único test QA que sirva para cualquier incorporación. Pero hay un patrón que funciona: una evaluación multinivel que separa pensamiento de pruebas de velocidad de codificación, juicio de conocimiento y arquitectura de sintaxis.

La mejor prueba QA no es la más difícil. Es la que revela si la candidatura va a mantener una suite de tests durante tres años sin quemarse.

Estructura ideal de la evaluación

Parte 1: diseño de casos de test (escrito, 30–45 minutos)

Innegociable. Es el primer filtro.

Da a las candidaturas una especificación realista — ni «testea el login» (demasiado vago) ni «escribe 100 casos» (demasiado). Algo en medio: «Aquí tienes una funcionalidad para importar usuarios desde CSV en bloque. Escribe 8–12 casos de test que propondrías a tu equipo».

Qué evalúas:

• Cobertura: ¿identifica casos límite (fichero vacío, 100k filas, caracteres especiales)?
• Claridad: ¿alguien podría ejecutarlos sin llamarla?
• Juicio: ¿prioriza casos críticos o trata todo igual?
• Realismo: ¿reconoce restricciones (setup de datos, entorno)?

Usa una rúbrica: cobertura 25 %, claridad 25 %, juicio 25 %, viabilidad 25 %. No es objetividad perfecta, pero es consistente.

Tiempo de corrección: 10–15 minutos por candidatura.

Parte 2: código de automatización (take-home, 2–3 horas)

Quien pase la parte 1 recibe una take-home: «Aquí tienes una app sandbox. Coge 4–5 de los casos que diseñaste y automatízalos. Usa el framework que conozcas».

Qué evalúas:

• Calidad del código: ¿legible, mantenible, no demasiado «listo»?
• Fluidez de framework: sintaxis válida, asserts correctos, esperas inteligentes
• Robustez: ¿el test sobrevive un cambio menor de UI o es frágil?
• Arquitectura: ¿usa page objects, setup, teardown?

No puntúes por velocidad. Quien escribe 2 tests sólidos en 2,5 h es más fuerte que quien escribe 8 rápidos.

Qué ignorar: si elige Selenium o Cypress, qué librerías usa. Esas son preferencias. Importa la calidad.

Tiempo de corrección: 15–20 minutos. Busca selectores que no se rompan, esperas con sentido, asserts que prueban comportamiento (no solo DOM), código humano.

Parte 3: entrevista de proceso en vivo (60 minutos)

Aquí brilla el juicio. Prepara 2–3 escenarios:

Escenario 1: «Tu suite de regresión dura 3 horas. El equipo quiere recortarla a 1 hora para desbloquear despliegues. ¿Cuál es tu jugada?»

Escenario 2: «Un bug crítico en producción se le escapó a tu suite. Es una condición de carrera 1 de 100. Cuéntame tu investigación».

Escenario 3: «Una funcionalidad lanza en 2 semanas. La cobertura no está completa. Lanzar sin cobertura nos expone a pérdida de datos. ¿Qué propones?»

Ninguna tiene respuesta correcta. Escucha:

• ¿Hace preguntas aclaratorias (tamaño de equipo, impacto de usuario, presupuesto)?
• ¿Articula trade-offs sin titubear?
• ¿Piensa como ingeniera (riesgo, ROI, mantenimiento) o solo como tester (cobertura)?
• ¿Es honesta sobre restricciones?

Tiempo: 20 minutos para preguntas, 10 para razonamiento, 30 para profundización y sus preguntas.

Parte 4 (opcional): revisión de código (30–45 minutos)

Si tu rol incluye revisar código de tests, añade esto.

Da una suite con 3–5 problemas: selector flaky, falta de manejo de errores, test sobre-aseverado, race condition en setup/teardown. Pídele identificar y proponer arreglos.

Qué evalúas:

• ¿Sabe leer y criticar código?
• ¿Entiende modos de fallo?
• ¿Sus sugerencias son prácticas o teóricas?

Solo necesario si tu equipo de verdad revisa código de tests.

Inversión total de tiempo

• Parte 1: 45 min candidata, 10–15 min corrección
• Parte 2: 2–3 h candidata, 15–20 min corrección
• Parte 3: 1 h candidata, 30 min entrevista, 10 min notas
• Parte 4 (opc): 30–45 min candidata, 10 min corrección

Total: 4–5 h de la candidatura, 1,5–2 h de quien recluta/entrevista. Razonable para una sénior.

Cribado previo

No mandes la take-home a todo el mundo. Usa la parte 1 como cribado.

Si no diseñan un caso coherente en 45 minutos, no escribirán automatización sólida. Reserva las 3 h de take-home para quien pase.

Tasa de paso aproximada: apunta al 40–60 % avanzando a take-home. Si es mucho más, tu rúbrica es laxa. Si es menos, tu spec puede ser confusa.

Calibración

Antes de contratar, calibra al equipo en qué es «bueno».

Pasa la evaluación a 2–3 buenas incorporaciones de tu equipo. ¿Qué pinta tienen sus casos? ¿Calidad de código? Esa es tu referencia.

Pasa luego a 2–3 contrataciones que no funcionaron. ¿Qué tenían de débil? Ese espacio negativo importa.

No buscas objetividad perfecta, sino consistencia.

Cuándo saltarte partes

QA manual (exploratorio, no automatización): salta partes 2 y 4. Foco en 1 y 3.

Mid-level con portfolio verificado: puedes saltarte la 1 y pasar a 2 y 3. Solo si has visto su código real.

Volumen alto, fase temprana: empieza con 1 + 3. Más rápido. Cuando el proceso esté estable, añade la 2 para finales.

Por qué supera a las alternativas

Mejor que problemas estilo LeetCode: miden velocidad bajo presión, no pensamiento de pruebas ni arquitectura.

Mejor que una sola entrevista en vivo: no puedes evaluar diseño de tests o mantenimiento en 60 minutos.

Mejor que solo portfolio: los portfolios están curados. La evaluación muestra la habilidad actual, no la mejor de hace tres años.

La estructura funciona porque separa señales. Diseño es distinto de calidad de código, distinto de juicio. Necesitas las tres.

Contraconsideración: tal vez estés contratando mal

Algunos equipos sostienen que hay que contratar engineers fuertes que recojan tests, no especialistas que solo saben testing.

Es justo si tus engineers son lo bastante fuertes. Pero los engineers fuertes contratados para «también hacer QA» a menudo no lo hacen. QA se vuelve una tarea que les molesta. Acabas con tests sin mantenimiento e ingeniería quemada.

Contrata a quien eligió esta disciplina. La evaluación te ayuda a encontrarlas.