Day in the Life of a QA Engineer

Te han llamado para una entrevista de QA Engineer y no sabes qué decir cuando te preguntan cómo es un día normal. O ya llevas unos meses en testing y sientes que nadie te explicó cómo se organiza de verdad el trabajo. Voy a describirte un día realista de un perfil mid-level, con sus reuniones, su trabajo de concentración y sus momentos de presión.

No es un día bonito de folleto. Hay tareas repetitivas, hay esperas, hay discusiones sobre si algo es bug o no. Pero también hay momentos en los que tu trabajo evita que miles de usuarios vean una pantalla roja.

La mañana: reuniones y contexto#

El día empieza entre las 8:30 y las 9:30, según la empresa y la zona horaria del equipo. Lo primero no es testear. Es leer.

Reviso Slack o Teams, miro si algo explotó en producción durante la noche y leo los comentarios en los tickets que tengo abiertos. Si el equipo tiene una daily, suele ser de 15 minutos. Ahí digo qué probé ayer, qué voy a probar hoy y si me bloquea algo.

La daily es corta pero no es el único punto de contacto. En un equipo ágil normal vas a tener tres o cuatro reuniones al día, y eso se come una parte enorme de tu tiempo.

• Daily de 15 minutos con el equipo de desarrollo
• Refinement o planning, una o dos veces por semana, entre 45 y 60 minutos
• Reuniones con producto para entender requisitos nuevos
• Sesiones de bug triage con desarrolladores
• Algunas retrospectivas o demos al final del sprint

En total, hay días en los que las reuniones ocupan dos horas y otros en las que ocupan cuatro. Si te dicen que un QA "solo prueba cosas", están mintiendo por omisión.

El trabajo de verdad: testear con concentración#

Después de la daily toca el bloque de mayor valor: el trabajo de concentración. Aquí es donde un QA mid-level marca la diferencia.

Esto puede ser diseñar casos de prueba para una funcionalidad nueva, ejecutar una batería de tests manuales, escribir o arreglar tests automatizados, o investigar un bug raro que nadie entiende. Lo normal es que hagas un poco de todo cada semana.

Un ejemplo concreto. Supongamos que el equipo lanza un cambio en el formulario de registro. Yo no me limito a rellenar el formulario una vez. Pienso en los casos raros: contraseñas de un solo carácter, correos con acentos, doble clic en el botón, pegar texto con emojis, navegar con el teclado, recargar la página a mitad del envío. Ese pensamiento lateral es el que da trabajo al QA.

Escribir tests automatizados también forma parte del día, sobre todo si tienes perfil técnico. En la mayoría de equipos modernos vas a tocar código aunque no seas desarrollador. Si esa parte te asusta, mejor que lo sepas ahora.

Las herramientas que se usan de verdad#

En las ofertas de empleo verás una lista interminable de tecnologías. En el día a día, la realidad es más estrecha. Estas son las que aparecen casi siempre:

• Jira, Azure DevOps o Linear para gestionar bugs y tareas
• Postman o algo similar para probar APIs
• Selenium, Cypress o Playwright para automatización web
• Jenkins, GitHub Actions o GitLab CI para correr los tests
• SQL, para consultar la base de datos y verificar datos
• Charles Proxy, DevTools del navegador o logs del servidor para investigar fallos
• Confluence, Notion o un wiki interno para documentar

No necesitas dominar todas. Necesitas dos o tres a fondo y la capacidad de aprender las otras cuando toque. Si quieres ver qué piden hoy las empresas, echa un vistazo a las ofertas de QA en nuestro buscador de empleo.

Los momentos de presión#

Aquí viene la parte que casi nadie cuenta. Un QA vive la presión de forma distinta a un desarrollador, pero vive.

La presión más habitual es la del final del sprint. Llega el viernes, hay que cerrar la versión, quedan bugs sin verificar y el equipo te pide confirmación rápida. Tu respuesta de "sí, está bien" o "no, falta esto" puede frenar un despliegue o dejar pasar un problema.

Otro punto de fricción: discutir con un desarrollador si algo es un bug. A veces tienes razón, a veces no. Lo que importa es defender tu postura con datos: pasos de reproducción, capturas, logs, comportamiento esperado frente a comportamiento real. Sin datos, tu opinión es solo una opinión.

También está la presión invisible de ser quien dice que no. Nadie es el invitado estrella de la fiesta cuando anuncia que la función no se puede lanzar. Aprende a decirlo con calma y sin dramatismo.

Lo que sorprende a los recién llegados#

Varias cosas. La primera: vas a pasar más tiempo leyendo y hablando con gente de lo que imaginabas. Entender el contexto de un cambio te lleva más tiempo que ejecutar el test.

La segunda: encontrarás bugs en sitios que no son código. En requisitos ambiguos, en textos mal traducidos, en permisos mal configurados. El software es más que el código.

La tercera: no vas a probar todo. Nunca. Tienes que decidir qué merece tu tiempo y qué no, y esa decisión es una de las habilidades más valiosas del rol. Al principio esto incomoda mucho.

Cómo cambia el rol de junior a senior#

Un junior ejecuta casos de prueba escritos por otros, reporta bugs con plantillas y pregunta antes de decidir. Es un rol de aprendizaje, y está bien.

Un mid-level diseña sus propios casos, investiga bugs sin ayuda constante y empieza a opinar sobre riesgos. Ya no solo pregunta "¿esto es un bug?", sino "¿esto merece bloquear el release?".

Un senior piensa en el sistema completo. Define la estrategia de testing del equipo, decide qué automatizar y qué no, anticipa dónde van a salir los problemas y forma a la gente más nueva. Pasa mucho menos tiempo ejecutando tests y mucho más tiempo evitando que los tests sean necesarios.

El salto no es solo técnico. Es de criterio y de comunicación. Si quieres seguir leyendo sobre cómo crecer en el sector, tenemos más artículos sobre carreras tech en nuestro blog.

Cómo prepararte para la entrevista#

Si vas a entrevistarte para un puesto de QA, prepara esto antes de entrar:

• Dos o tres bugs que hayas encontrado y cómo los documentaste
• Un ejemplo donde tu prueba evitó un problema en producción
• Qué herramientas usas y en qué contexto concreto
• Un caso donde no pudiste probar todo y cómo priorizaste
• Tu postura sobre cuándo automatizar y cuándo no
• Algo que hayas aprendido de un bug que se te escapó

Y una cosa práctica: antes de cualquier entrevista técnica, pasa tu CV por un verificador de compatibilidad con ATS. Muchas empresas filtran automáticamente y un CV mal estructurado ni siquiera llega a ojos humanos.

También te recomiendo leer con calma la descripción del puesto antes de aplicar. Un decodificador de ofertas de empleo te ayuda a entender qué está pidiendo realmente la empresa y qué es relleno.

Herramientas gratis#

• jobrise.io/es/free-ats-checker/
• jobrise.io/es/free-jd-decoder/
• jobrise.io/es/jobs/
• jobrise.io/es/blog/

Preguntas frecuentes#

¿Cuánto gana un QA Engineer?

Depende mucho del país, la experiencia y si el perfil es manual o de automatización. Como referencia orientativa, los sueldos de QA mid-level van desde rangos modestos en Latinoamérica hasta cifras bastante más altas en España, Europa y Estados Unidos, y varían según la empresa. Consulta siempre la fuente oficial o portales actualizados de tu país antes de negociar.

¿Hay que saber programar para ser QA?

No para empezar, sí para crecer. Puedes entrar como QA manual con conocimientos básicos de SQL y lógica, pero llegar a mid-level o senior casi siempre exige escribir tests automatizados y leer código con soltura.

¿El trabajo de QA es repetitivo?

Parte sí. Ejecutar los mismos casos de prueba cada sprint se vuelve mecánico. Lo interesante está en diseñar esos casos, investigar fallos raros y decidir qué merece atención, que es donde pasas la mayor parte del tiempo a medida que avanzas.

¿Qué diferencia hay entre QA manual y QA de automatización?

El QA manual ejecuta pruebas a mano y se enfoca en explorar el comportamiento real de la aplicación. El de automatización escribe scripts que repiten pruebas de forma programada, y suele requerir más base técnica. En la práctica, muchos equipos piden una mezcla de ambos.

¿Cómo consigo mi primer empleo como QA sin experiencia?

Empieza por aprender fundamentos de testing, SQL y alguna herramienta como Jira y Postman, y documenta tus prácticas como si fueran bugs reales. Un curso de ISTQB Foundation ayuda en algunos mercados, pero lo que más pesa es mostrar casos concretos de cómo piensas al probar.