3 conceptos clave que evaluadores técnicos buscan en entrevistas de QA

Hay una diferencia enorme entre saber testing y poder demostrarlo en una entrevista técnica. No te das una idea de la cantidad de gente llega a esas instancias habiendo estudiado, con cursos encima, con proyectos en el portfolio, y aun así se traba. No porque no sepa, sino porque no tiene claro qué es lo que el evaluador del otro lado realmente está mirando. Y cuando no sabés qué buscan, es difícil mostrar lo que tenés.

Después de hablar con muchos testers que pasaron por ese proceso (y de preparar a otros para enfrentarlo en las mentorías), hay tres cosas que aparecen una y otra vez en las entrevistas técnicas de QA. No son trucos. Son las bases que cualquier evaluador con criterio va a querer ver en acción.

1. Cómo pensás, no solo qué ejecutás

Lo primero que un evaluador técnico observa no es si sabés usar Jira o Selenium. Observa cómo razonás frente a un problema de testing que nunca viste antes.

Te van a dar un formulario, una historia de usuario, una feature sin especificación completa y van a pedirte que hablés en voz alta mientras lo analizás. Ahí es donde se nota la diferencia. ¿Preguntás sobre los casos borde antes de tirar los primeros casos? ¿Identificás ambigüedades en el requerimiento? ¿Pensás en usuarios reales o solo en el happy path?

El evaluador no necesita que llegues a la respuesta "correcta". Necesita ver que tu proceso de pensamiento tiene estructura. Que no ejecutás a ciegas.

Esto me recuerda a cuando, de jóven, estudiaba química, física sin meterle práctica. Me aprendía las fórmulas de memoria, todo bien…pero cuando algo cambiaba ligeramente de cómo lo vi en el happy path de la teoría, no tenía idea de cómo encarar el problema.

2. Diseño de casos de prueba con criterio

Saber diseñar casos de prueba es una habilidad técnica concreta, y la mayoría de los evaluadores la van a poner a prueba de manera directa. "Dame los casos de prueba para este campo de texto", "¿qué cubrirías primero y por qué?", "¿cómo priorizarías si solo tenés tiempo para tres casos?".

Acá no alcanza con listar escenarios al azar. Un evaluador con experiencia quiere ver que conocés técnicas: partición de equivalencia, análisis de valores límite, tablas de decisión. No para que recites definiciones, sino para que las apliques sin que nadie te lo pida explícitamente.

Y ojo también con qué tipo de puesto es al que estamos aplicando. Si es algo que pide API Testing, el tipo de pruebas va a ser diferente que si tenemos que testear E2E en la UI. Así que eso tenelo muy, pero muy en cuenta.

Lo que diferencia a alguien preparado de alguien que simplemente "hace testing" es que el primero tiene un lenguaje técnico para justificar sus decisiones. Y eso se entrena.

3. Precisión para hablar de defectos

Encontrar un bug es la parte fácil. Saber comunicarlo con precisión es lo que separa a un tester junior de uno que genera confianza desde el primer día.

En una entrevista, te pueden pedir que describas un bug que encontraste, que evalúes un reporte de defecto ya escrito, o que expliques la diferencia entre severidad y prioridad con un ejemplo concreto. Y ahí se nota rápido si tenés el vocabulario o si estás improvisando.

Un evaluador técnico quiere escuchar cosas como: contexto claro, pasos reproducibles, habilidad técnica para proveer logs, comportamiento esperado vs. comportamiento real, y algún criterio para clasificar el impacto. Si llegás a esa parte de la entrevista sin haber practicado cómo hablar de bugs, el conocimiento que tenés no se va a ver.

Estas tres cosas: razonamiento visible, diseño técnico de casos, y comunicación de defectos, no se aprenden de memoria. Se practican. Y hay una diferencia entre estudiarlas en abstracto y aplicarlas en situaciones que simulan lo que vas a enfrentar en una entrevista real.

Si querés prepararte de manera estructurada para ese momento, QA Job Ready es el curso que armé específicamente para eso: para que cuando llegues a esa silla, sepas exactamente qué mostrar y cómo mostrarlo.

Es el primer paso, justo antes de ponerte a prueba con lo desafiante de un proyecto real en la Clínica de Free Range Testers. Pero eso…es tema para otro momento.

¿Qué parte de las entrevistas técnicas de QA te genera más incertidumbre — el diseño de casos, hablar de bugs, o algo completamente distinto?