Cómo redactar un CV para un puesto de QA engineer

Qué busca primero un responsable de contratación

Quien contrata a un QA engineer no lee tu CV de arriba abajo en la primera pasada. Busca tres cosas, más o menos en este orden: qué probaste (el dominio — fintech, salud, e-commerce, embebidos, juegos), cómo lo probaste (manual, automatizado, o ambos, y en qué capa — unitaria, API, UI, end-to-end), y con qué lo probaste (las herramientas específicas mencionadas en su stack). Si estas tres cosas no son visibles en el primer tercio de la página, el CV se deja de lado, porque el lector tiene una pila de ellos y un anuncio de trabajo que nombró herramientas específicas por una razón.

Por eso "profesional orientado al detalle con excelentes habilidades de comunicación" en la parte superior de un CV de QA es espacio muerto. No le dice al lector nada que no pueda asumir, y empuja la información útil — Selenium, Playwright, Postman, lo que sea — más abajo en la página donde podría perderse en una lectura rápida.

Pon tu stack de automatización y alcance de testing en las primeras líneas, ya sea como un breve resumen o como una línea de habilidades directamente bajo tu nombre. No una nube de habilidades con cuarenta herramientas en orden alfabético — el puñado que realmente has usado en producción, con suficiente especificidad para que alguien que lo lea sepa inmediatamente si hay coincidencia con su stack.

Titulaciones y certificaciones: qué señalan realmente

QA no es una profesión colegiada — no hay equivalente a un examen de abogacía o un registro de enfermería. Nadie está verificando un registro antes de que puedas llamarte QA engineer. Eso significa que las certificaciones aquí funcionan de manera diferente que en campos regulados: son una señal de base formal, no un requisito legal, y los responsables de contratación varían mucho en cuánto peso les dan.

El ISTQB Foundation Level (y los niveles Advanced y Expert superiores, si los tienes) es la certificación con más probabilidades de ser reconocida a primera vista por un responsable de contratación de QA, porque es lo más cercano que tiene el campo a un vocabulario compartido — niveles de prueba, tipos de prueba, ciclo de vida de defectos, la terminología usada en planes de prueba. No te conseguirá una entrevista por sí sola, pero omitirla si la tienes es un error: algunos sistemas de seguimiento de candidatos y algunos responsables de contratación sí filtran por ella.

Más allá de ISTQB, lo que más importa son las credenciales específicas de herramientas y cloud que se mapean directamente con el anuncio de trabajo: certificaciones AWS o Azure si el rol toca pruebas de infraestructura cloud, un Certified Selenium Professional o similar si la automatización es central, credenciales de testing de seguridad como OSCP o CEH si el rol tiene un componente de pruebas de seguridad (cada vez más común en anuncios de QA que piden habilidades cercanas a penetración). Lista estas cerca de tu nombre o en una breve línea de "certificaciones", no enterradas al final bajo educación — un responsable de contratación que busca una credencial específica mencionada en el anuncio mirará primero cerca de la parte superior.

Un título en informática o ingeniería de software ayuda pero no se trata como una barrera de la manera en que podría serlo para algunas disciplinas de ingeniería — muchos QA engineers en activo se movieron desde otros ámbitos técnicos o incluso no técnicos, y los CVs que muestran un historial claro de testing tienden a superar un título faltante o no relacionado. Si tu título no está relacionado con software, no te disculpes por ello ni lo justifiques — deja que la sección de experiencia hable.

Cómo evidenciar tu experiencia en testing

Aquí es donde la mayoría de los CVs de QA fallan, y es el mismo error en cada caso: listar responsabilidades en lugar de resultados de testing. "Responsable de probar el módulo de checkout" no le dice al lector nada sobre lo que realmente hiciste o qué cambió por ello.

Lo que un responsable de contratación de QA quiere ver, para cada rol, es alguna combinación de:

• Qué probaste y en qué nivel — unitario, integración, API, UI, end-to-end, rendimiento, seguridad, accesibilidad. Nombrar el nivel le dice al lector dónde te sitúas en la pirámide de testing, que es una distinción real en este campo y afecta lo que un rol realmente necesita.
• Qué encontraste y qué pasó con ello. No un recuento de defectos por sí solo (un recuento alto de bugs puede significar testing exhaustivo o una funcionalidad mal construida — no se lee como inequívocamente positivo), sino la forma del trabajo: clasificaciones de severidad que usaste, cómo se triaron los defectos, si escribiste los pasos de reproducción que hicieron que una corrección se desplegara más rápido.
• Qué automatizaste, y el antes-y-después. "Reduje el ciclo de regresión de tres días de ejecución manual a una suite automatizada de dos horas" es concreto y verificable en una entrevista, que es exactamente por qué funciona mejor que "mejoré la eficiencia del testing".
• Cobertura, donde puedas declararla honestamente. Los porcentajes de cobertura de pruebas se citan comúnmente en CVs de QA, pero son un proxy para la exhaustividad, no una prueba de ella — un responsable de contratación que ha hecho este trabajo preguntará qué midió la herramienta de cobertura y si fue cobertura de línea, rama o requisito. Si citas un número, prepárate para decir qué midió.
• Tu posición en el proceso de release. ¿Tenías la aprobación final para un release, o ejecutabas casos de prueba que alguien más escribió? ¿Escribiste el plan de pruebas, o seguiste uno? Esta es una de las señales más claras de seniority en QA y rutinariamente se deja implícita en lugar de declarada.

Escribe casos de prueba y reportes de bugs de la manera en que los escribirías para un ticket real: específico, reproducible, con el resultado declarado. Un responsable de contratación que ha leído miles de tickets de bugs vagos notará un punto de CV que se lee como uno.

Herramientas, frameworks y vocabulario que pertenecen a este CV

El genérico "competente en herramientas de testing" es invisible. Nombra el stack real, porque los nombres de las herramientas están haciendo trabajo de filtrado real, tanto para un humano hojeando la página como para cualquier coincidencia de palabras clave en un sistema de seguimiento de candidatos.

Frameworks y herramientas de automatización: Selenium, Playwright, Cypress, Appium (para móvil), TestNG, JUnit, PyTest — y con qué lenguaje los emparejaste, ya que "Selenium" solo no le dice al lector si lo escribiste en Java, Python o C#.

Testing de API y capa de servicio: Postman, REST Assured, SoapUI — nómbralos por separado de la automatización de UI, porque el testing de API y el testing de UI son habilidades diferentes y un anuncio de trabajo que especifica uno te está diciendo cuál necesitan.

CI/CD e integración de pipeline: Jenkins, GitHub Actions, GitLab CI, CircleCI. Declarar que tu suite automatizada se ejecutaba como parte de un pipeline, en lugar de dispararse manualmente, señala una práctica de testing más madura que un script standalone ejecutado a mano.

Gestión de defectos y pruebas: JIRA (y específicamente si usaste Xray o Zephyr junto con él), TestRail, qTest. Vale la pena nombrarlos porque diferentes equipos de QA se estandarizan en diferentes, y la familiaridad con la herramienta específica en el anuncio de trabajo elimina fricción de onboarding en la que el responsable de contratación está pensando.

Testing de rendimiento y carga: JMeter, Gatling, k6 — vale la pena una línea separada si lo tienes, ya que es un conjunto de habilidades distinto del testing funcional y a menudo lo que separa a un QA engineer mid-level de uno senior.

Testing de accesibilidad: axe, WAVE, o testing manual de conformidad WCAG — cada vez más solicitado y rara vez listado, lo que hace que valga la pena incluirlo si realmente lo has hecho.

Control de versiones y vocabulario de entornos: Git, Docker, entornos de staging versus producción, feature flags. Los QA engineers que pueden hablar de cómo probaron a través de entornos, no solo qué probaron, se leen como más senior.

Qué se deja fuera, y no debería

Algunas cosas que los QA engineers omiten rutinariamente, no por deshonestidad sino porque no piensan en mencionarlas:

La escala de lo que probaste. Número de casos de prueba mantenidos, tamaño de la suite de regresión, número de entornos o combinaciones de navegador/dispositivo cubiertas. Estos números son concretos y le dan a un responsable de contratación una idea del tamaño de la operación sin necesidad de preguntar.

Si trabajaste en un equipo Agile y cuál fue tu rol en el ciclo de sprint — escribir criterios de aceptación, probar dentro del sprint versus después, participación en planificación de sprint o retrospectivas. La participación de QA en ceremonias Agile varía mucho entre empresas y vale la pena declararla en lugar de asumirla.

Trabajo multifuncional con desarrolladores. Si hiciste pair con desarrolladores en desarrollo guiado por pruebas, revisaste pull requests, o escribiste pruebas que se ejecutaban como parte del propio flujo de trabajo del desarrollador en lugar de una pasada QA separada. Esta distinción — QA como gate al final versus QA embebido en desarrollo — es algo por lo que los responsables de contratación activamente filtran, y rara vez se declara claramente.

Cualquier testing exploratorio que hayas hecho, distinto de la ejecución de casos de prueba scriptados. Es una habilidad real y valorada en este campo y no aparece en un recuento de pruebas automatizadas, así que tiene que declararse directamente o es invisible.

Qué hacer a continuación

Pon el anuncio de trabajo junto a tu CV y verifica que las herramientas específicas, niveles de testing y certificaciones que nombra aparezcan en tu CV con las mismas palabras, cerca de la parte superior. Reescribe tus tres roles más recientes como resultados de testing, no responsabilidades — qué probaste, qué encontraste, qué automatizaste, y qué cambió como resultado. Corta el párrafo de resumen que podría describir a cualquier ingeniero y reemplázalo con tu stack y dominio reales.

Si estás enviando CVs más rápido de lo que puedes adaptarlos a lo que cada anuncio pide específicamente, ahí es donde suele venir el silencio — no de la calidad del trabajo detrás del CV. jobmarket.pro lee cada anuncio completo, lo compara con un perfil en el que no puede inventar experiencia, y prepara la solicitud a partir de eso.