Calidad de Software · 2026
CV Harvard para Ingeniero/a QA
Tu CV es una suite de pruebas: demuestra calidad medible, no una lista de herramientas.
¿Cómo se hace un CV de Ingeniero/a QA en formato Harvard?
A un Ingeniero/a QA lo contratan equipos que buscan una sola cosa al revisar tu CV: ¿subió la calidad porque estuviste ahí? En productoras, fintech, consultoras y squads ágiles miran primero la tasa de defectos escapados a producción, la cobertura de automatización, el tiempo del ciclo de regresión y los frameworks que de verdad mantienes — no un muro de logos de herramientas que abriste una vez. El formato Harvard de una página te obliga a pasar de 'probé la aplicación' a resultados: menos incidentes en prod, pipelines más rápidos, flakiness llevado a cero. Lidera con trabajo de calidad cuantificado, mantén las certificaciones acotadas y escribe cada viñeta como un reporte de pruebas con un resultado medible.
Qué buscan los recruiters
- Resultados de calidad cuantificados: tasa de defectos escapados reducida, incidentes en prod a la baja, runtime de la suite de regresión (4h → 35min), % de cobertura de automatización de los flujos críticos
- Profundidad real en automatización con nombre propio: Selenium/WebDriver, Cypress, Playwright, Appium, REST Assured, Postman/Newman — con el lenguaje (Java/TypeScript/Python) y el framework que construiste o mantienes
- Integración de pruebas en CI/CD: tests que bloquean PRs en Jenkins/GitHub Actions/GitLab CI, paralelización, cuarentena de flaky tests y su impacto en el tiempo de build
- Profundidad de estrategia: pruebas basadas en riesgo, pirámide de testing, BDD/Gherkin (Cucumber/SpecFlow), contract testing (Pact) y cómo decidiste qué automatizar vs. explorar
- Pruebas de performance y de API: JMeter, k6, Gatling, latencia p95/p99 validada, umbrales de throughput y tasa de error exigidos en el pipeline
- Certificaciones que abren la puerta: ISTQB Foundation / Advanced (Test Analyst, Test Automation Engineer) y certs de herramienta/cloud cuando el stack lo pide
Secciones requeridas, en este orden
Lidera con Resultados de Calidad, No con un Muro de Herramientas
- Pon una sección de Experiencia compacta justo después de Educación; abre cada viñeta con el resultado (defectos escapados a la baja, ciclo más corto, más cobertura), no con la herramienta
- Indica el alcance dentro de la viñeta — 'escribí 320+ pruebas E2E automatizadas en 6 microservicios' le muestra al revisor tu radio de impacto al instante, sin línea de skills
- Agrupa un pie de 'Habilidades Técnicas' por Automatización / API y Performance / CI-CD / Gestión de Pruebas para que el ATS haga match sin una sopa de 30 ítems
- Elimina las herramientas de 'conocimiento básico' — lista solo frameworks que construiste, mantienes o podrías codear en vivo en una entrevista
Aprovecha Educación, Certificaciones e ISTQB al Estilo Harvard
- Educación primero, una línea cada una: título, institución, año de egreso — omite el promedio salvo que sea sobresaliente y reciente
- Pon las certificaciones vigentes (ISTQB Foundation/Advanced, ISTQB Test Automation Engineer) bajo Educación con el nivel y el año obtenido
- Si programas, demuéstralo: muestra el framework de pruebas que diseñaste y el lenguaje, porque los CV de QA solo manual quedan filtrados para roles SDET
- Venir de un bootcamp o ser autodidacta está bien — el formato Harvard premia suites entregadas y métricas de cobertura por encima del pedigrí
Una Página, Limpio para ATS, Disciplina de Texto Plano
- Sin foto, sin fecha de nacimiento, sin gráficos ni barras de habilidad — tus reportes de pruebas no llevan barras de progreso y tu CV tampoco
- Una sola columna, fuentes estándar, sin tablas ni cuadros de texto — los layouts a varias columnas los destrozan los parsers de ATS
- Escribe el término y luego la sigla una vez: 'Sistema Bajo Prueba (SUT)' y 'Software Development Engineer in Test (SDET)' para que coincidan ambas variantes de keyword
- Orden cronológico inverso, viñetas con verbo de acción (Automaticé, Construí, Reduje, Migré) — cada línea se gana su lugar o se va
Ejemplo en formato Harvard
Bullets fuertes vs débiles
Encargado de escribir y ejecutar casos de prueba para la aplicación web.
Construí un framework E2E en Playwright + TypeScript que cubre el 92% de los flujos críticos de usuario en 6 microservicios, reduciendo el ciclo de regresión manual de 3 días a 40 minutos y detectando 14 defectos bloqueantes antes de staging en el primer trimestre.
Nombra el stack (Playwright/TypeScript), la cobertura (92% de los caminos críticos), la escala (6 microservicios) y el resultado (tiempo de ciclo y defectos detectados). El revisor entiende 'esta persona es dueña de la automatización de punta a punta' en segundos.
Trabajé en mejorar la automatización y reducir los tests inestables.
Bajé el flaky rate de la suite de CI del 18% a menos del 1% aislando condiciones de carrera asíncronas, agregando esperas determinísticas y poniendo en cuarentena los tests inestables en GitHub Actions — recuperando la confianza del equipo y desbloqueando más de 40 merges diarios.
Métrica antes/después (18% → <1%), las técnicas concretas (condiciones de carrera, esperas determinísticas, cuarentena) y el impacto de negocio (40+ merges diarios desbloqueados). Es madurez en automatización, no un vago 'trabajé en'.
Hice pruebas de performance sobre la API.
Diseñé pruebas de carga en k6 simulando 5.000 usuarios concurrentes contra la API de checkout, exponiendo una fuga en el connection pool que limitaba el throughput a 220 req/s; validé que el fix mantuviera la latencia p95 bajo 180ms y lo dejé como umbral del pipeline.
Nombra la herramienta (k6), la carga (5.000 usuarios virtuales), la causa raíz hallada (fuga en el connection pool) y el SLO exigido (p95 < 180ms). Se lee como una investigación de performance real, no como 'hice pruebas'.
Reporté bugs y trabajé con los desarrolladores para corregirlos.
Reduje la tasa de defectos escapados a producción un 64% en dos ciclos de release introduciendo priorización de pruebas basada en riesgo y contract tests de API con shift-left (Pact), bajando los bugs Sev-2 reportados por clientes de 22 a 8 por trimestre.
La métrica estrella de calidad (defectos escapados −64%), la estrategia que la generó (basada en riesgo + contract testing) y el resultado de cara al cliente (Sev-2 de 22 a 8). Es justo el número que el hiring manager de QA busca primero.
Errores comunes específicos
- Listar más de 30 herramientas como un muro plano de keywords. El reclutador valora profundidad sobre amplitud — agrupa 4-6 categorías y lista solo frameworks que construiste o podrías codear en vivo.
- Describir funciones en vez de resultados ('encargado de escribir casos de prueba'). Cada viñeta necesita un número: defectos escapados, % de cobertura, ciclo reducido o flakiness eliminado.
- Decir 'pruebas manuales y automatización' sin evidencia de código. Para roles SDET/automatización, nombra el framework que diseñaste y el lenguaje, o quedas filtrado.
- Ocultar el alcance. 'Probé la app' no dice nada; '320 pruebas E2E en 6 microservicios, 92% de cobertura de caminos críticos' le muestra al revisor tu radio de impacto real.
- Irte a dos páginas con detalle exhaustivo de casos de prueba. La disciplina Harvard es una página — si una viñeta no tiene métrica ni alcance, es relleno, córtala.
Tu CV empieza aquí. Decides después si pagas.
Empezar mi CVPreguntas frecuentes
- ¿Listo pruebas manuales y automatización por separado o solo lo más fuerte?
- Lidera con automatización — es lo que abre la puerta en la mayoría de roles QA y SDET modernos y en los filtros ATS. Mantén lo manual/exploratorio como señal de criterio (pruebas basadas en riesgo, charters exploratorios, juicio sobre casos borde), pero que el CV no se lea como solo-manual. Nombra el framework que construiste, el lenguaje y la cobertura lograda. La profundidad en un stack de automatización real le gana a la sopa de logos.
- ¿Cómo cuantifico el trabajo de QA si no 'lanzo features'?
- Tus métricas son calidad y velocidad, no features. Cuantifica la tasa de defectos escapados, el porcentaje de detección de defectos, la cobertura de automatización de flujos críticos, el tiempo de ciclo de regresión, el flaky rate y los incidentes de prod evitados. Suma números de performance (latencia p95/p99 validada, throughput) e impacto en CI (tiempo de build, merges desbloqueados). Es justo lo que el hiring manager de QA escanea primero.
- ¿Necesito la certificación ISTQB?
- No es obligatoria, pero abre muchos roles y filtros ATS, sobre todo en empresas grandes, consultoras y los mercados de España y LatAm. ISTQB Foundation es una base sólida; Advanced (Test Analyst o Test Automation Engineer) ayuda en roles senior y de liderazgo. Pon las certs vigentes bajo Educación con el nivel y el año. Para roles SDET, el código demostrado y un framework mantenido pesan más que la cert — muestra ambos.
- ¿De verdad cabe un CV de QA en una página con todo el detalle de pruebas?
- Sí, y así debe ser. La regla Harvard de una página te obliga a reducir el detalle de casos de prueba a resultados cuantificados. Pon el alcance en la viñeta ('320 pruebas E2E, 92% de cobertura de caminos críticos') en vez de un párrafo, cierra las habilidades en un pie agrupado y deja que hablen las métricas. El revisor dedica unos 7 segundos — una página densa y orientada a resultados le gana a dos páginas de relleno.