Cómo evaluar QA engineers: construyendo proceso de hiring para test automation

Por qué el hiring QA está roto

La mayoría de las empresas evalúa QA engineers como programmers con badge de QA. Hacen preguntas algorítmicas, corren coding tests, miden velocidad de syntax. Pero QA engineering no es programming con tools diferentes. Es disciplina diferente: trade-offs y juicio bajo restricción.

Una candidata rápida con Selenium puede ser terrible priorizando qué testear. Alguien que no codea Cypress puede excel encontrando bugs críticos vía exploración manual.

Las tres capas de evaluación QA

Capa 1: diseño de test cases (escrito, 45 min)

Spec de feature realista. Pídeles 12-15 test cases. Sin código.

Qué medir:

• Cobertura: identifican happy path, error, edge, transiciones de estado?
• Claridad: otra persona puede leer y ejecutar?
• Priorización: marcan crítico vs nice-to-have?
• Awareness de contexto: preguntan sobre environment?

Submission fuerte: precondiciones, pasos, expected outcomes, por qué importa cada caso.

Capa 2: portfolio de automation (take-home, 2-3 horas)

Proyecto open-source pequeño o sandbox app. Que escriban 4-6 tests automatizados en su framework.

Qué medir:

• Fluencia framework: código válido, runnable
• Estructura: independientes, legibles, mantenibles
• Robustez: waits, error handling, selectors estables
• Documentación: explican por qué su approach

Pregunta clave: "Si esto rompe mañana, ¿cómo debugeas?"

Capa 3: proceso y juicio (live, 60 min)

"Tenemos suite de 2 horas. Cortarla a 30 min. ¿Qué haces?" o "Feature lanza en 2 semanas, testing no terminó. ¿Tu jugada?"

Esto aplica a interview loops senior: mides juicio.

Qué medir:

• Estratégico (riesgo, ROI) vs táctico
• Push back sin confrontar
• Contexto de negocio
• Articulan trade-offs

Capa opcional: review de código

Si el rol incluye revisar tests, ejercicio de code review.

Hiring a escala

• Gradar test cases
• Sandbox para automation
• Grabar live coding

Red flags

• Sobre-automation
• Sub-automation
• Absolutismo de framework
• Falta contexto
• Sin priorización

Test automation engineers vs manual QA

Automation (80% código): framework + estructura. Manual (80% estrategia): test cases, edge cases.

Entrevista de proceso aplica a ambos.