Scorecard de entrevista para Ingeniero de QA
Un scorecard estructurado para entrevistar a un Ingeniero de QA: seis competencias con pesos, qué es realmente un 1 y qué es un 5, y preguntas que sacan evidencia en vez de opiniones. Imprimilo o copialo a tu ATS.
El scorecard para Ingeniero de QA
| Competencia | Peso | Puntaje 1 — cómo se ve | Puntaje 5 — cómo se ve |
|---|---|---|---|
| Diseño de pruebas y criterio de cobertura Si puede decidir qué vale la pena probar, porque probar todo es imposible y elegir la cobertura es el criterio central del rol. | 20% | Escribe casos que copian los criterios de aceptación línea por línea, sin casos de borde, negativos ni de transición de estado más allá de lo que decía el ticket. | Explica cómo eligió los casos de una feature concreta: qué bordes tomó, qué combinaciones dejó afuera a propósito y qué riesgo justificaba dejarlas afuera. |
| Investigación y reporte de defectos Si un desarrollador puede actuar sobre su reporte sin una segunda conversación, que es lo que define cuánto del tiempo de QA se convierte en bugs arreglados. | 18% | Carga reportes que dicen qué se veía mal, sin pasos, entorno ni datos, y reabre tickets que se cerraron como no reproducibles. | Reduce el defecto a los pasos mínimos de reproducción, dice qué cambia entre una corrida que pasa y una que falla, y adjunta el log o request que fija la falla. |
| Ingeniería de automatización de pruebas Si la suite automatizada se mantiene confiable con el tiempo, porque una suite inestable que todos ignoran cuesta más que no tener suite. | 18% | Automatiza lo que es más fácil de scriptear y trata las fallas intermitentes como ruido esperable para volver a correr, en lugar de diagnosticarlas. | Describe un test flaky que arregló desde la causa — un supuesto de timing, estado compartido entre corridas — y cómo cambió la confiabilidad de la suite después. |
| Criterio de riesgo en el release Si puede decir qué es seguro liberar y qué no, porque QA suele ser la última voz informada antes de que un release salga a producción. | 16% | Reporta cuántos casos pasaron y cuántos fallaron y escala todos los defectos por igual, sin distinguir un problema cosmético de una pérdida de datos. | Recuerda un release que recomendó liberar con un defecto conocido, qué exposición estimó y qué mitigación acordó con producto antes de salir. |
| Entornos, datos de prueba y herramientas Si puede llegar por su cuenta a un entorno de prueba realista, que es donde se acumula la mayor parte del tiempo perdido en el trabajo de QA. | 14% | Queda bloqueado cada vez que un entorno de prueba no está disponible, y no sabe cómo se creaban o refrescaban los datos de prueba en su rol anterior. | Describe un problema de datos o de entorno que resolvió — fixtures cargadas, una dependencia mockeada — y qué destrabó para el resto del equipo. |
| Trabajo con desarrollo y producto Si los problemas de calidad se resuelven en lugar de escalarse, porque QA tiene influencia pero rara vez autoridad sobre lo que sale a producción. | 14% | Explica la fricción pasada como que desarrollo ignoraba sus reportes, sin contar qué cambió en la forma de plantear el problema. | Describe cómo logró que se actuara sobre un problema de calidad: con quién lo planteó, qué evidencia lo sostuvo y qué concesión aceptó a cambio. |
Los pesos suman 100. Acordalos antes de la primera entrevista, no después: ajustar pesos cuando ya hay puntajes es la forma en que un panel justifica a su favorito.
Preguntas que sacan evidencia
Cada una pide algo que ya pasó, con suficiente detalle como para verificarlo. Las hipotéticas premian el ensayo, no la trayectoria.
- ¿Cómo decidiste qué casos escribir para la última feature que probaste, y qué riesgos aceptaste conscientemente dejar sin cubrir?
- ¿Qué defecto llegó a producción a pesar de tus pruebas? ¿Cómo se filtró y qué cambiaste después?
- ¿Cuál fue el test más flaky que te tocó? ¿Cuál era la causa real y cómo confirmaste que era esa?
- ¿Con qué release no te sentiste cómodo? ¿Cuál era el riesgo, con quién lo planteaste y qué se terminó decidiendo?
- ¿Qué contenía el último reporte de bug que cargaste, y cuántas idas y vueltas hicieron falta antes de que el desarrollador pudiera reproducirlo?
Señales de alarma
- Define su trabajo como ejecutar casos de prueba escritos por otra persona, sin incidir en la cobertura.
- No puede nombrar un defecto que se le haya escapado a producción ni qué aprendió de eso.
- Vuelve a correr los tests que fallan hasta que pasen y da el build por verde.
- Describe la calidad como una barrera que impone y no como un riesgo que ayuda al equipo a sopesar.
Cómo usar este scorecard
- Acordá los pesos con el panel antes de que alguien entreviste, y dejalos por escrito.
- Cada entrevistador puntúa todas las competencias por separado, con una nota que cite lo que el candidato dijo textualmente.
- Comparen los puntajes antes de discutirlos. Discutir primero ancla al panel en quien habla más fuerte.
Armar un scorecard a medida → · Cadena booleana para buscar Ingeniero de QA →
Preguntas frecuentes
¿Cuál es la diferencia entre un ingeniero de QA y un SDET al contratar?
Los títulos se superponen distinto en cada empresa. Conviene definir qué parte del rol es testing exploratorio y criterio de riesgo, y qué parte es construir y mantener infraestructura de automatización, y ponderar la entrevista en consecuencia. Contratar un perfil volcado a automatización para un rol mayormente exploratorio es un desajuste frecuente y caro.
¿Cómo evalúo habilidades de QA en una entrevista sin ejercicio para llevar?
Alcanza con mostrarle una feature en vivo o una especificación escrita y preguntarle qué probaría primero, qué dejaría afuera y por qué. Después conviene leer un reporte de bug real que haya escrito y juzgarlo solo por su reproducibilidad. Las dos cosas entran en media hora.
¿Qué debería pesar más en un scorecard de QA?
El criterio de cobertura y la calidad del reporte de defectos suelen llevarse el mayor peso, porque definen si el resto del trabajo sirve para algo. Los pesos se fijan antes de entrevistar y la evidencia se registra junto a cada puntaje. Verdict aplica el mismo enfoque al screening de CVs, atando cada puntaje a una línea citada del documento.
Cuando lo que está en juego es una contratación real, usá evidencia
Estas herramientas son heurísticas rápidas. Verdict lee el CV contra tu descripción de puesto y puntúa seis dimensiones con citas textuales como evidencia — un documento de contratación que podés defender.