Currículum de ingeniero/a de automatización de pruebas (QA automation): ejemplos y guía para redactarlo

Una página para un ingeniero de automatización en un equipo de producto que publica cada semana. El nombre y las empresas son inventados. Fíjate en que el stack aparece con nombres exactos, la suite se describe por tamaño y tiempo de ejecución, y los resultados se expresan en lo que le importa a un responsable de entrega: confianza en la publicación, rapidez del feedback y defectos escapados.

La selección para automatización se parece cada vez más a la de desarrolladores, y el filtro es técnico. Cuatro cosas lo deciden.

• En qué escribes código y cuánto. Lenguaje, framework y si construiste una suite o mantuviste una que escribió otra persona. Crear desde cero y heredar un desastre son experiencias valiosas, pero son historias distintas y debes decir cuál viviste.
• Si tu suite es fiable. La tasa de pruebas inestables es la cifra que lo decide. Una suite de 2.000 pruebas en la que nadie confía es peor que 300 pruebas que siempre significan algo, y los responsables lo saben.
• Rapidez del feedback. Tiempo de ejecución de la suite, paralelización y si las pruebas se ejecutan en cada pull request o solo por la noche. El feedback rápido es el producto real que entrega un ingeniero de automatización.
• Impacto más allá de la suite. Defectos detectados antes de publicar, defectos escapados después, horas manuales eliminadas, versiones por trimestre que se hicieron posibles. Esto es lo que convierte un currículum de QA en uno de ingeniería.

“Lo primero que busco es una tasa de pruebas inestables y un tiempo de ejecución. Si alguien me dice que llevó una suite de cuatro horas a once minutos y bajó las pruebas inestables por debajo del uno por ciento, ya sé que puede hacer el trabajo. Una lista de veinte herramientas sin ninguna cifra al lado me dice que ha visto muchos tutoriales.”

Tres o cuatro líneas: stack, tamaño y tiempo de ejecución de la suite, una cifra de fiabilidad y una de impacto. Ajústalo a tus años, pero no quites nunca las cifras.

Las cifras salen de tu panel de CI, tus informes de pruebas y tu gestor de defectos, y puedes consultarlas hoy mismo.

Agrupa por capas para que quien lee vea la forma de tu experiencia, y prepárate para defender cada línea en una entrevista técnica o en un ejercicio de programación en directo.

• Lenguajes, con el que mejor dominas primero: TypeScript, JavaScript, Python, Java, C#. Piensa cuál elegirías para un proyecto nuevo y por qué, porque te lo van a preguntar.
• Automatización web: Playwright, Selenium WebDriver, Cypress, WebdriverIO. Indica el patrón que usas, como page objects o fixtures basados en componentes, y si lo construiste o lo heredaste.
• Pruebas de API y de servicios: REST Assured, Supertest, requests con pytest, Postman y Newman, pruebas de contrato entre servicios, validación de esquemas JSON, mocks y stubs.
• Móvil, si lo haces: Appium, Espresso, XCUITest, nubes de dispositivos y cómo gestionas la matriz de dispositivos.
• Test runners y estructura: Jest, pytest, JUnit 5, TestNG, pruebas parametrizadas, fixtures y hooks, etiquetado y ejecuciones selectivas.
• CI e infraestructura: GitHub Actions, Jenkins, GitLab CI, Azure DevOps, Docker, Kubernetes si lo usas, estrategia de paralelización y sharding, recogida de artefactos y trazas.
• Rendimiento y carga: k6, JMeter, Gatling, y si ejecutaste las pruebas o solo leíste los resultados.
• Gestión de pruebas e informes: Jira, Xray, TestRail, Zephyr, Allure y cualquier panel de pruebas inestables que hayas creado.
• Práctica de ingeniería: Git y revisión de pull requests, revisión de código de las pruebas de otras personas, trabajo en pareja con desarrolladores y lectura de logs de la aplicación para averiguar qué falló de verdad.

Es la vía de entrada más habitual a este puesto y los responsables de selección lo saben. Lo que quieren ver es código real que has escrito, no un certificado que diga que has estudiado automatización.

1. 1Automatiza algo en tu trabajo actual, aunque no tengas permiso para cambiar la estrategia. Los smoke tests más repetidos son el lugar más seguro para empezar, y «automatización de los 60 smoke tests más repetidos, con la ejecución reducida de 3 horas a 25 minutos» es una historia completa.
2. 2Elige un lenguaje y un framework y domínalos. Abarcar cinco herramientas queda peor que dominar a fondo TypeScript y Playwright, o Java y Selenium.
3. 3Sube código que funcione a GitHub con un readme que explique las decisiones de diseño. Los responsables los abren, y un proyecto pequeño y limpio gana a uno grande y desordenado.
4. 4Aprende la parte de CI. Conseguir que las pruebas se ejecuten en GitHub Actions o Jenkins, en paralelo y con informes, es lo que separa a un tester que escribe scripts de un ingeniero de automatización.
5. 5Mantén visible tu experiencia en pruebas manuales en lugar de esconderla. Las pruebas exploratorias, el análisis de riesgos y saber dónde fallan de verdad los productos son cosas que a menudo les faltan a los desarrolladores puros, y los mejores ingenieros de automatización conservan ambas.
6. 6Añade ISTQB Foundation si no tienes nada más sobre el papel y después el nivel Test Automation Engineer. Ninguno sustituye al código, pero ambos ayudan cuando un/a reclutador/a filtra candidaturas.

• Una página hasta unos 8 años de experiencia y dos a partir de ahí. Los currículums de ingeniería se leen rápido y se escanean buscando el stack.
• Pon el stack cerca del principio, en un bloque de competencias o en el perfil. Los reclutadores filtran por nombres de frameworks antes de que un responsable técnico vea tu candidatura.
• Una sola columna, sin gráficos ni barras de nivel. Nadie se cree un gráfico de barras que diga que dominas Python al 85 %.
• Incluye un enlace a GitHub y asegúrate de que los repositorios fijados son los que quieres que lean. Un perfil vacío o abandonado es peor que no poner enlace.
• Refleja el vocabulario de la oferta: «automatización de pruebas», «SDET», «Playwright», «Selenium», «Cypress», «Appium», «REST Assured», «CI/CD», «pipeline», «suite de regresión», «flaky», «page object», «pruebas de contrato», «shift left».
• Deja claro qué construiste y qué mantuviste. Las dos cosas están bien; la ambigüedad, no.
• En PDF, con tu nombre y el puesto en el nombre del archivo.

Cuenta con que la entrevista incluya escribir o arreglar una prueba en directo, una conversación sobre qué no automatizarías y una pregunta sobre cómo gestionas una prueba inestable que falla una vez por semana. Ten respuestas reales y asegúrate de que las cifras que das coinciden con las de tu currículum.