Los parsers de ATS eliminan el formato antes de escanear: si pones tus habilidades en una tabla de dos columnas, el sistema puede no leer nada en esa sección. El matching de palabras clave también es literal: una oferta que dice "TypeScript" no va a coincidir con "TS", y "Playwright" no va a coincidir con "automation framework". Este artículo cubre la estructura, la estrategia de palabras clave y el formato de bullets de experiencia que pasan el parser y todavía se leen bien para un hiring manager.
Cómo funciona el ATS realmente
Un ATS no es una IA que evalúa tu currículum de forma integral. Es un sistema de matching de palabras clave. Cuando un reclutador publica un trabajo, define (o el software define) un conjunto de palabras clave requeridas. El ATS escanea cada currículum enviado buscando esas palabras clave. Los currículums que coinciden con suficientes palabras clave pasan. Los que no se filtran antes de que alguien los lea.
El ranking no es sofisticado. "5 años de Playwright" y "Playwright" coinciden con la misma palabra clave. El sistema no lee en profundidad; verifica la presencia.
Hay algunas cosas adicionales que el ATS hace y que atrapan a los candidatos de QA:
Parsea texto plano
Muchos sistemas de ATS eliminan el formato de archivos Word o PDF y procesan solo el texto sin formato. Las tablas, cuadros de texto, encabezados/pies de página y columnas se vuelven imposibles de parsear o se omiten por completo. Si pones tus habilidades en una tabla de dos columnas, el ATS puede no ver nada en esa sección.
Lee los encabezados de sección literalmente
"Experiencia Profesional" e "Historial Laboral" funcionan. "Mi Recorrido" y "Dónde He Estado" confunden a los parsers. Usa nombres de sección estándar.
Busca en lugares predecibles
Los bullets de experiencia se parsean como experiencia. El contenido en logos basados en imágenes, gráficos o PDFs escaneados desde papel no se parsea en absoluto.
La implicación práctica: un currículum limpio y amigable con texto plano, formateado con encabezados de sección convencionales, sin tablas y con las palabras clave correctas, va a superar a un currículum visualmente impresionante que el ATS no puede leer.
Las palabras clave que realmente usan las ofertas de QA
Cada oferta de trabajo es una pista de palabras clave. Las habilidades listadas en la sección de requisitos son exactamente lo que el ATS está buscando. Tu trabajo es reflejar el lenguaje de la oferta en tu currículum: no para inventar habilidades, sino para usar la misma terminología que usa la empresa.
Las palabras clave más requeridas en las ofertas de trabajo de automatización de QA en 2026:
Herramientas y frameworks: Playwright, Selenium, Cypress, WebDriverIO, TypeScript, JavaScript, Python, Java Tipos de testing: API testing, end-to-end testing, regression testing, integration testing, performance testing, load testing Infraestructura y proceso: CI/CD, GitHub Actions, Jenkins, GitLab CI, Docker, Agile, Scrum, JIRA, Git Conceptos y patrones: Page Object Model, test automation framework, cobertura de pruebas, estrategia de testing, reportes de bugs, seguimiento de defectos Específico de API: REST API, Postman, HTTP, request/response, status codes, JSONEl ATS no hace matching de sinónimos a menos que esté configurado explícitamente para hacerlo. Usa los términos exactos.
Estructura del currículum para candidatos de QA
El orden de las secciones importa porque tanto los parsers de ATS como los lectores humanos tienen expectativas. Esta estructura funciona para QA automation engineers en todos los niveles de experiencia:
1. Información de contacto
Nombre, email, URL de LinkedIn, URL de GitHub, ciudad y país (no dirección completa). Incluye tu perfil de GitHub. Para roles de QA automation, es tan relevante como LinkedIn.
2. Resumen (3 a 4 líneas)
Un breve resumen profesional al inicio, escrito en primera o tercera persona sin "yo". Acá es donde adelantas tus palabras clave más importantes y dejas claro a qué rol apuntas. No escribas un "Objetivo". Los objetivos hablan de lo que quieres, y eso no le importa a los hiring managers. Un resumen habla de lo que ofreces.
Ejemplo: "QA Automation Engineer con 2 años de experiencia construyendo suites de pruebas con Playwright y TypeScript. Enfocado en integración de CI/CD y API testing. Con experiencia en equipos Agile en empresas de producto."
3. Habilidades
Una sección corta y escaneable que lista herramientas y tecnologías. Más sobre cómo formatearla a continuación.
4. Experiencia
Orden cronológico inverso. Empresa, título, fechas y 3 a 5 bullets por rol. Los bullets son donde la mayoría de los currículums pierde puntos (ver la siguiente sección).
5. Proyectos
Especialmente importante si tienes experiencia profesional de QA limitada. Acá van lab.becomeqa.com y tu portafolio de GitHub. Trata cada proyecto como un trabajo: dale un título, una descripción de una línea, las tecnologías usadas y 2 a 3 bullets de logros.
6. Educación y certificaciones
Título si es relevante, ISTQB si lo tienes, cursos completados que valgan la pena mencionar. Mantenlo corto.
Este orden coloca el contenido más relevante (resumen, habilidades y experiencia) donde tanto el ATS como el lector humano esperan encontrarlo.
Escribir bullets de experiencia que muestren impacto
Acá es donde fallan la mayoría de los currículums de QA. El currículum típico de QA está lleno de descripciones de tareas: "escribí tests automatizados", "realicé regression testing", "reporté bugs". Estas le dicen al lector qué hiciste, pero no qué efecto tuvo. Un bullet sólido muestra un resultado.
El esquema: verbo de acción + qué hiciste + resultado medible (cuando sea posible).
Ejemplos antes y después:
| Antes | Después |
|-------|---------|
| Escribí tests automatizados para el flujo de checkout | Construí una suite de 40 tests de Playwright cubriendo el flujo de checkout end-to-end, reduciendo el tiempo de regresión manual en 3 horas por sprint |
| Mejoré la velocidad de ejecución de tests | Reduje el tiempo de ejecución de la suite de regresión un 40% migrando a ejecución paralela con Playwright workers |
| Corregí tests flaky | Diagnostiqué y eliminé 12 tests flaky causados por race conditions, llevando la estabilidad de la suite del 78% al 97% |
| Escribí tests de API | Implementé 60+ tests de API REST en Postman/Newman cubriendo autenticación, operaciones CRUD y escenarios de error |
| Trabajé con el equipo de desarrollo | Introduje un proceso de QA shift-left que detectó 8 bugs críticos en la etapa de desarrollo antes de llegar a staging |
No todos los bullets necesitan un número. Pero cada bullet debería tener un resultado específico, no solo una actividad. Si no puedes encontrar un número, sé específico sobre el alcance o la relevancia: "la única cobertura de pruebas automatizadas para el módulo de pagos" es más informativo que "tests de pago automatizados".
Usa verbos de acción fuertes al inicio de cada bullet: construí, reduje, eliminé, implementé, introduje, migré, aumenté, mantuve, diagnostiqué, documenté. Evita: "responsable de", "ayudé con", "estuve involucrado en".
Sección de habilidades: herramientas sin el volcado de palabras clave
Una sección de habilidades que parece una lista de spam se ve mal para el lector humano aunque pase el ATS. El objetivo es ser escaneable y creíble, no exhaustivo.
Agrupa tus habilidades por categoría en lugar de listar todo en un bloque:
Frameworks de testing: Playwright, Selenium WebDriver, Cypress
Lenguajes: TypeScript, JavaScript, Python
API y performance: Postman, REST API, k6
CI/CD y DevOps: GitHub Actions, Jenkins, Docker, Git
Gestión de tests: JIRA, Confluence, TestRail
Metodologías: Agile, Scrum, Page Object ModelAlgunas reglas para esta sección:
Solo lista herramientas de las que puedas hablar en una entrevista. Si incluyes "k6" y un hiring manager te pide que expliques un script de load test, tienes que poder hacerlo. Listar herramientas que apenas tocaste es una forma rápida de fallar un screening técnico.
No califiques tus habilidades con estrellas, barras o porcentajes. "Playwright ★★★★☆" no le dice nada objetivo al lector y parece poco profesional. Si la conoces, lístala. Si eres principiante, los bullets en tu sección de experiencia lo mostrarán.
Mantén la sección concisa: 6 a 8 categorías, 3 a 5 ítems cada una. Todo lo que pertenece acá es algo que quieres destacar; todo lo demás puede aparecer de forma orgánica en tus bullets de experiencia.
El problema "sin experiencia formal en QA"
La pregunta más común de personas que entran a QA desde bootcamps, cambios de carrera o estudio autodidacta: "¿Qué pongo en la sección de experiencia si todavía no tengo un trabajo de QA?"
La respuesta es: pones experiencia. No tiene que ser empleo remunerado.
Proyectos personales con alcance real
Una suite de tests de Playwright contra lab.becomeqa.com con estructura de Page Object Model, 20+ tests y un pipeline de GitHub Actions en verde es trabajo real de QA. Descríbelo en tu sección de Proyectos exactamente como describirías un trabajo. Incluye las tecnologías, el alcance (qué probaste) y los resultados (cobertura de tests, configuración de CI, cuánto tiempo llevó).
Proyectos de bootcamp o curso
Si completaste un curso de QA con tareas prácticas, esas tareas son proyectos. Si construiste una suite de tests como parte del curso, eso pertenece a tu sección de Proyectos con un link al repositorio de GitHub.
Contribuciones a proyectos de código abierto
Añadir tests a un proyecto open source, aunque sea pequeño, es trabajo profesional de QA. Demuestra que puedes navegar un código ajeno y escribir tests que cumplen los estándares de otra persona.
Experiencia no QA reenmarcada
Si trabajaste en soporte, documentaste bugs. Si trabajaste en desarrollo, probaste código. Si trabajaste en QA manual, eso es relevante aunque apuntes a roles de automatización. Describe lo que realmente hiciste usando terminología de QA.
lab.becomeqa.com está construido específicamente para este escenario. Un QA engineer que aplica a su primer rol de automatización con un portafolio de GitHub que muestra 25 tests de Playwright pasando, una configuración de POM estructurada y un pipeline de CI en verde es más competitivo que un candidato con vagas "2 años de experiencia en testing" sin nada que mostrar.El currículum te consigue la entrevista. El portafolio te consigue la oferta.
Errores comunes que hacen que rechacen currículums de QA
Declaraciones de objetivo
"Busco un rol desafiante de QA donde pueda crecer" es relleno. Reemplázalo con un resumen que describa lo que ofreces.
Fotos
No incluyas una foto a menos que apliques en un país donde sea práctica estándar (no lo es en EE.UU., UK, Canadá o la mayor parte de Europa). Las fotos crean riesgo de sesgo para los hiring managers, y algunas empresas instruyen específicamente a los reclutadores a descartar currículums con fotos.
Tablas y cuadros de texto en documentos Word
Los parsers de ATS frecuentemente fallan con contenido dentro de tablas de Word. Usa un diseño simple de una sola columna. Si usas columnas (por ejemplo, un diseño de dos columnas con habilidades a un lado e información de contacto al otro), verifica el output guardando como texto plano y comprobando que todo siga ahí.
PDFs de plantillas complejas
No todos los PDFs son iguales. Un PDF exportado desde una plantilla de Canva frecuentemente tiene capas de texto que los sistemas de ATS no pueden parsear. Usa un PDF simple generado desde un documento Word limpio o un archivo de Google Docs.
Responsabilidades, no resultados
Cada bullet que empieza con "Responsable de" o "Participé en" es un bullet que podría ser más fuerte. Reescríbelo con un verbo de acción y un resultado específico.
Fechas inconsistentes
Los vacíos están bien y no necesitan ocultarse. Los rangos de fechas inconsistentes o imposibles (por ejemplo, dos roles de tiempo completo superpuestos sin explicación) generan dudas. Sé consistente con el formato: "Ene 2024 – Mar 2025" o "Enero 2024 – Marzo 2025", no una mezcla.
Currículums genéricos
Un currículum que lista cada herramienta que tocaste alguna vez y está dirigido a "roles de QA en general" rinde peor que uno adaptado a una oferta específica. Más sobre esto en la siguiente sección.
Adaptar para cada solicitud
Un currículum adaptado supera notablemente a uno genérico. La diferencia no es porque los hiring managers prefieran los adaptados (frecuentemente no pueden distinguirlos). Es porque el porcentaje de coincidencia de palabras clave del ATS es más alto cuando tu currículum refleja el lenguaje específico de la oferta.
El proceso de adaptación lleva unos 5 minutos por solicitud:
1. Lee la descripción del trabajo. Anota cada término técnico en las secciones de requisitos y deseables.
2. Compáralos con tu currículum. ¿Están presentes todos esos términos? Si tienes la habilidad pero usaste terminología diferente, actualízala.
3. Ajusta tu resumen. Cambia una oración para reflejar el rol o tipo de empresa específico (startup vs. empresa grande, producto vs. consultoría).
4. Revisa los bullets de experiencia al inicio. Si tienes trabajo relevante que no está destacado de forma prominente, reordenas los bullets o añades uno que hable a un requisito clave.
Mantén un "currículum maestro" que incluya todo lo que hiciste, y crea una versión adaptada para cada solicitud recortando, reordenando y ajustando palabras clave. Guarda la versión adaptada como un archivo nuevo (por ejemplo, cv-playwright-fintech-mayo2026.pdf) para saber qué enviaste a quién.
Las empresas donde más quieres trabajar reciben cientos de solicitudes. Los candidatos que consiguen callbacks generalmente no son los más calificados. Son los cuyo currículum pasó el filtro y fue legible cuando un humano finalmente lo leyó.
Preguntas frecuentes
¿El ATS ve todo lo que pongo en mi currículum?No. El contenido dentro de tablas, cuadros de texto, encabezados, pies de página y elementos gráficos se pierde frecuentemente. Usa un diseño plano de una sola columna para cualquier currículum enviado a través de un portal de solicitud en línea. Guarda como un PDF estándar generado desde un procesador de texto, no desde una herramienta de diseño.
¿Qué tan largo debería ser un currículum de QA?Una página si tienes menos de 5 años de experiencia. Dos páginas si tienes 5 o más años y genuinamente necesitas el espacio. Nunca rellenes para alcanzar la longitud. El espacio en blanco está bien. Un currículum al 80% lleno de contenido sólido es mejor que uno al 100% lleno de contenido más débil añadido para completar páginas.
¿Debería incluir ISTQB u otras certificaciones?Sí si las tienes, en la sección de Educación/Certificaciones. Son una señal positiva leve, especialmente para empresas que las mencionan en las descripciones de trabajo. No listes certificaciones "en progreso" a menos que esperes completarlas antes de empezar el rol.
¿Qué hago si la descripción del trabajo lista una herramienta que no conozco?Si la tocaste aunque sea mínimamente (incluso en un proyecto personal), menciónala. Si nunca la usaste, no la listes como habilidad. Sí menciona en tu resumen o carta de presentación que tienes experiencia con herramientas comparables y aprendes rápido. Listar habilidades que no tienes solo va a causar problemas en las entrevistas técnicas.
Apliqué a 50 trabajos sin ningún callback. ¿Qué está mal?Las causas más comunes, en orden de frecuencia: el currículum no pasa el matching de palabras clave del ATS, el formato del currículum impide el parsing correcto, los bullets de experiencia describen tareas en lugar de resultados, y no hay portafolio ni link de GitHub para roles de automatización. Audita tu currículum contra el checklist de este artículo. Si no tienes portafolio, construye uno en lab.becomeqa.com antes de seguir aplicando.
Para la mayoría de las empresas, no. No se lee antes de que el currículum pase el ATS, y muchos hiring managers la omiten por completo. Escribe una corta (3 a 4 párrafos) para los roles que realmente quieres, pero no inviertas tiempo significativo aquí hasta que tu currículum esté sólido.
→ See also: Cómo Construir un Portfolio de QA que Te Consigue Trabajo (GitHub + Playwright) | Optimización de LinkedIn para Ingenieros QA: Perfil, Titular, About, Habilidades | Trabajos QA Remotos en 2026: Dónde Encontrarlos y Cómo Conseguirlos | Negociación Salarial para Ingenieros QA: Cómo Pedir Más (y Conseguirlo)