Qué evaluar antes de entrevistar a un QA tester

Un QA recibe un build, lo prueba con los datos de siempre, marca todo en verde y lo aprueba. Tres días después, un usuario en producción ingresa un monto con coma en vez de punto, el sistema redondea mal y se factura de menos durante una semana. Nadie lo vio venir, porque nadie pensó en ese caso. El bug no estaba en la herramienta de testing: estaba en la mentalidad de quien probó.

Ese es el problema central al contratar QA. El CV te dice qué herramientas conoce esa persona, pero no te dice si piensa en los casos límite antes de que exploten. Y en QA, esa forma de pensar es justamente lo que separa a quien atrapa el bug caro de quien lo deja pasar.

Por qué el CV no alcanza para este cargo

Un CV de QA suele ser una lista de tecnologías: Selenium, Postman, Cypress, JMeter, una metodología ágil y “experiencia en pruebas funcionales y de regresión”. Todo eso es real y útil, pero ninguna línea responde la pregunta que de verdad importa: ¿cómo razona esta persona frente a un sistema que todavía no sabe cómo se va a romper?

Las herramientas se aprenden en semanas. La mentalidad de detalle, la sospecha sana ante un “esto ya funciona” y la capacidad de imaginar cómo un usuario real puede usar mal el producto no aparecen en una certificación. Por eso el CV te ordena candidatos por años de experiencia, no por calidad de pensamiento. Y en tecnología, donde un defecto se replica a miles de usuarios en minutos, esa diferencia es lo que cuesta caro.

Qué señales observar más allá de las herramientas

Antes de entrevistar, conviene mirar evidencia de cómo la persona enfrenta un problema, no solo qué declara saber. Hay tres señales que vale la pena buscar de forma comparable entre candidatos:

• Razonamiento estructurado: cómo descompone un escenario en casos, incluyendo los que nadie pidió probar (entradas vacías, límites, concurrencia, estados intermedios).
• Atención al detalle bajo carga: si mantiene precisión cuando la tarea se vuelve repetitiva o ambigua, que es exactamente cuando se escapan los bugs.
• Comunicación del defecto: un buen QA no solo encuentra el problema, lo reporta de forma reproducible para que otro lo arregle sin adivinar.

La idea es evaluar antes de entrevistar, con señales comparables entre todos los postulantes, para no llegar a la reunión apoyándote solo en la impresión que deja el CV.

Cómo combinar competencias según el cargo

Un QA tester no es un perfil de una sola dimensión. Según el contexto del equipo, conviene combinar competencias en vez de medir una sola cosa: razonamiento lógico para diseñar casos, atención al detalle para no dejar pasar lo obvio, y comprensión funcional para entender qué espera el negocio del producto.

Esa combinación cambia según el cargo. Un QA que trabaja codo a codo con desarrollo necesita más afinidad técnica y lectura de lógica, cercana a la de un desarrollador. Un QA en un equipo de producto orientado al usuario necesita más empatía con el flujo real y menos foco en la automatización. Definir esa mezcla por adelantado evita evaluar a todos con la misma vara cuando los cargos no son iguales.

Qué mirar en el reporte antes de la entrevista

Cuando revisas los resultados, el objetivo no es un número que decida por ti, sino una lectura que te prepare. Busca la señal de ajuste al cargo para priorizar a quién entrevistar primero, y luego baja al detalle: ¿dónde mostró razonamiento sólido y dónde flaqueó? Un candidato fuerte en lógica pero débil en comunicación no se descarta, se entrevista con foco en esa brecha.

El reporte también incluye controles de integridad, para que la evidencia que comparas sea confiable entre candidatos. Eso te da un criterio común dentro del equipo de selección, en vez de tres opiniones que no se pueden contrastar. Si quieres ver cómo se estructura ese material, la biblioteca y el producto muestran qué tipo de reportes obtienes para preparar cada conversación.

Preguntas de entrevista basadas en evidencia

La entrevista deja de ser un interrogatorio genérico y pasa a profundizar en lo que ya viste. Algunas preguntas que parten de la evidencia:

• “En la prueba diseñaste casos para entradas válidas. Cuéntame los tres casos límite que probarías en un formulario de pago.” (mide profundidad real, no la del CV)
• “Encontraste un bug intermitente que no se reproduce siempre. ¿Cómo lo documentas para que desarrollo no lo cierre como ‘no reproducible’?”
• “Tu resultado fue alto en razonamiento y más bajo en atención al detalle. ¿Cómo te organizas en tareas largas de regresión?”

Cada pregunta nace de una señal observada. Así decides con respaldo y el equipo mantiene la decisión final; Kokoro apoya la decisión, no la toma por ti.

En resumen

El CV de un QA te dice qué herramientas tocó, no cómo piensa frente a lo que aún no se ha roto. Antes de entrevistar, observa razonamiento, detalle y comunicación con señales comparables; combina las competencias según el tipo de QA que necesitas; usa el reporte para priorizar y para preparar preguntas concretas; y entra a la entrevista con evidencia, no con corazonadas. Así inviertes tus horas de entrevista en los candidatos correctos, y dejas de descubrir los casos límite en producción.