Prueba de QA: cómo evaluar testers de verdad

Encontrar bugs obvios es la parte más fácil del trabajo de un QA, y es también lo único que llega a medir una prueba de QA improvisada. Lo que distingue a un buen tester es anticipar los casos que nadie pensó probar, y priorizar qué probar primero cuando el tiempo no alcanza para probarlo todo. Una prueba que solo pide "encuentra los errores en esta pantalla" no mide ninguna de las dos cosas.

Qué distingue a un buen QA

Un buen QA piensa en casos límite de forma sistemática, no solo prueba el camino feliz que el desarrollador ya validó. Entiende que no todos los bugs tienen el mismo impacto, y prioriza según riesgo real para el usuario y el negocio, no según lo primero que encontró. Y comunica los defectos de forma que un desarrollador pueda reproducirlos sin ida y vuelta innecesaria, con pasos claros, datos de entrada y comportamiento esperado versus observado.

Estas tres capacidades importan más que el conocimiento de una herramienta de automatización específica, que se puede enseñar. El criterio para diseñar buenos casos de prueba es mucho más difícil de desarrollar después de contratar.

Diseño de casos de prueba

Pide al candidato que, dada una funcionalidad simple como un formulario de registro, diseñe un plan de casos de prueba sin ejecutarlos todavía. Un buen plan cubre casos válidos, casos inválidos, casos límite como campos vacíos o con el largo máximo permitido, y casos de interacción entre campos, como una fecha de nacimiento que hace a alguien menor de edad en un formulario que requiere ser mayor.

Evalúa si el candidato agrupa los casos por prioridad, no solo los lista sin ningún orden. Un plan de veinte casos sin priorización es menos útil que uno de doce casos ordenados por impacto y probabilidad de ocurrencia.

Criterio de riesgo

Un QA con buen criterio de riesgo sabe que no todo merece la misma profundidad de prueba. Pide al candidato que, frente a una funcionalidad de pago y una funcionalidad de preferencias de notificación, explique cómo distribuiría su tiempo de prueba entre ambas y por qué.

La respuesta correcta no es un número exacto, es el razonamiento: la funcionalidad de pago tiene mayor impacto si falla, mayor probabilidad de generar pérdida económica o legal, y por eso merece más profundidad de prueba que una funcionalidad de bajo riesgo, aunque ambas parezcan similares en esfuerzo de desarrollo.

Ejercicio de ejemplo para una prueba de QA

Entrega una pantalla de checkout con una descripción funcional breve, sin acceso al código, y pide al candidato que en 45 minutos escriba un plan de prueba priorizado y ejecute manualmente los cinco casos que considere más importantes, documentando cualquier defecto encontrado con pasos de reproducción claros.

Evalúa con una rúbrica de cuatro criterios: cobertura de casos relevantes, incluyendo límites y combinaciones no obvias; priorización con justificación clara del riesgo; calidad de la documentación de los defectos encontrados; y capacidad de explicar, en la conversación posterior, qué probaría distinto con más tiempo disponible.

Para ver cómo evaluar la automatización de estas mismas pruebas dentro de un flujo de integración continua, en test de DevOps está la guía completa con ejercicios prácticos. Si el rol toca también la capa de servicios, en prueba de backend está qué mide una buena evaluación, y los criterios para revisar el código de las pruebas automatizadas están en evaluación de código.

Una prueba de QA que evalúa diseño de casos y criterio de riesgo distingue mejor el nivel real que una cacería de bugs. Si quieres aplicarla con rúbrica y comparar candidatos con el mismo criterio, puedes agendar una demo.

Preguntas frecuentes

¿Un QA debe saber programar para ser evaluado con este ejercicio?
No necesariamente. Este ejercicio evalúa pensamiento de prueba manual, que es una habilidad independiente de la capacidad de automatizar. Si el rol requiere automatización, conviene sumar un ejercicio técnico específico para eso.

¿Cuánto tiempo debería durar la prueba completa?
Entre 45 y 60 minutos para el diseño y ejecución del plan, más 15 a 20 minutos de conversación posterior sobre las decisiones tomadas.

¿Cómo distingo a un QA junior de uno senior con este mismo ejercicio?
El nivel junior suele cubrir los casos obvios con ejecución correcta. El nivel senior identifica casos límite no evidentes, prioriza con criterio de negocio explícito, y anticipa interacciones entre funcionalidades que el enunciado ni siquiera menciona.

¿Debo incluir automatización en la primera etapa de evaluación?
Depende del rol. Para roles de QA manual o de análisis de calidad, el pensamiento de prueba pesa más. Para roles de QA automation, conviene evaluar ambas cosas, con la automatización como una etapa adicional después de confirmar buen criterio de prueba.