Un CV de tester QA lo leen dos personas con intereses muy distintos. La persona de seleccion busca los nombres de herramientas que aparecen en la oferta, y luego el responsable de calidad que te entrevista revisa cada punto con una duda concreta: si encuentras errores de verdad o si te limitas a ejecutar scripts escritos por otra persona. La mayoria de los curriculos de testers convencen al primero y pierden al segundo.
Aqui hablamos solo de lo propio del testing. Si apuntas a desarrollar funcionalidades, encaja mejor el texto sobre el CV de ingeniero de software, y la infraestructura y las guardias corresponden al CV de DevOps y SRE.
Primero, el camino: pruebas manuales, automatizacion o ambas
En las consultoras tecnologicas de Madrid, Barcelona o Valencia conviven dos perfiles de QA que se contratan con criterios diferentes. Uno viene de las pruebas funcionales y de aceptacion; el otro, del desarrollo y la automatizacion. Un curriculum que intenta cubrir los dos a la vez suele no convencer en ninguno.
Para un puesto de QA manual o funcional, quien contrata busca criterio. Le interesa tu forma de elegir los puntos a probar, la calidad de un reporte de incidencia que un desarrollador puede resolver sin escribirte tres mensajes, y tu conocimiento de los usuarios del producto.
Para un puesto de automatizacion o de SDET, el lector espera codigo. Quiere conocer el lenguaje de tus pruebas, el framework de base, si mantienes la suite o solo sumas casos, y la forma en la que las pruebas corren dentro del pipeline.
Si haces las dos cosas, pon delante la que la oferta prioriza. La frase bajo tu nombre tiene que decirlo sin rodeos: "QA funcional y de API, sector banca" transmite algo muy distinto a "Ingeniero de automatizacion de pruebas, TypeScript y Playwright".
Las herramientas: nombrarlas y ponerlas a trabajar
Muchos testers enumeran cada herramienta que alguna vez han instalado. El texto sobre ejemplos de competencias en el CV trata ese bloque en general; para QA, lo util es agrupar las herramientas por funcion:
- Automatizacion de interfaz: por ejemplo Selenium, Cypress o Playwright
- Pruebas de API: Postman, o un cliente dentro de tu propio framework
- Pruebas unitarias y de integracion: JUnit, pytest o el equivalente de tu stack
- Gestion de pruebas: la herramienta de gestion de casos que use tu equipo
- Seguimiento de incidencias: un gestor de tickets como Jira
Despues, cada herramienta importante tiene que reaparecer dentro de un punto de experiencia, unida a un resultado. "Cypress" en una lista solo demuestra que conoces el nombre. "Has rehecho en Cypress la suite de regresion del proceso de pago y la pasada manual baja de dos dias a una tarde" demuestra lo que haces con ella. Las cifras de este ejemplo son ilustrativas; usa las tuyas, y solo las que puedas explicar en una entrevista.
Conviene ser honesto con el nivel real. Tres scripts de Selenium en un proyecto personal van en un apartado de proyectos, no junto al framework que mantienes desde hace cuatro ejercicios.
Tu forma de pensar: estrategia, preparacion de las pruebas y testing exploratorio
Este es el apartado que la mayoria de los curriculos de QA se salta, y el que separa a un tester senior de alguien que solo ejecuta. Quien contrata quiere ver que eres capaz de mirar una funcionalidad y localizar el riesgo.
- La estrategia de pruebas. Si has escrito o ajustado el enfoque de pruebas de una version, de un producto nuevo o de una migracion, dilo, junto con tus prioridades. "Plan de pruebas basado en riesgos para el cambio de pasarela de pago, centrado en devoluciones y casos frontera de divisas" resulta concreto y creible.
- La definicion de casos de prueba. Nombra las tecnicas que aplicas de verdad, como valores frontera, particiones de equivalencia o transiciones de estado, pero solo si puedes explicar un ejemplo. Una tecnica unida a una funcionalidad real vale el doble que cinco nombres seguidos.
- El testing exploratorio. Si haces sesiones con tiempo acotado, un objetivo y notas, describelas. De ahi salen a menudo los errores interesantes, y muchos testers lo infravaloran porque no deja un entregable vistoso.
A quien te entrevista no le importa el volumen de pruebas ejecutadas. Le importa saber si eres capaz de frenar el fallo que le ha costado caro a su equipo este trimestre.
Incidencias, cobertura y metricas de entrega sin cifras de escaparate
Las cifras ayudan a un CV de QA, pero las habituales son flojas. "2.000 casos de prueba ejecutados" no dice nada del valor aportado, y "400 incidencias registradas" puede significar un producto mal construido o erratas contadas una a una.
Las metricas utiles hablan del efecto en el equipo o en la puesta en produccion:
- la parte de un flujo esencial cubierta por pruebas automaticas, y el cambio que eso supone (menos parches urgentes, validaciones antes)
- la duracion de una pasada de regresion antes y despues de tu trabajo
- las pruebas inestables que has estabilizado
- un fallo grave que has frenado antes de produccion, contado en una frase con el riesgo de negocio en juego
Queda el tema delicado: los fallos que llegan a produccion. No hace falta listarlos, pero una frase honesta sobre tu respuesta ante uno de ellos pesa bastante. "Tras un error de precios en produccion, he incorporado pruebas de contrato entre los servicios de precios y de carrito; sin repeticiones de ese tipo de fallo desde entonces" demuestra responsabilidad.
Cada cifra tiene que ser defendible. Si no sabes explicar la forma de medirla, quitala.
Integracion continua, shift-left y el salto a SDET
El testing actual vive dentro del pipeline de entrega, y tu CV tiene que mostrar tu sitio en esa cadena. Si tus pruebas corren en cada pull request, escribelo. Si has montado la ejecucion en paralelo, los informes de pruebas o la puerta de calidad que bloquea una fusion, eso es ingenieria de verdad y merece su propio punto.
El shift-left conviene nombrarlo porque cambia el papel del tester. Revisar los criterios de aceptacion antes del desarrollo, trabajar en pareja con desarrolladores en las pruebas unitarias o incorporar pruebas de contrato entre servicios adelanta las pruebas en el ciclo, y demuestra que influyes en la calidad en lugar de solo medirla.
Contar el paso de tester manual a SDET
En el curriculum, el paso de las pruebas manuales a un rol de SDET tiene que resultar creible:
- No cambies la denominacion del puesto que has tenido. Deja que los puntos de experiencia muestren el peso creciente de la automatizacion.
- Pon el codigo primero en cada puesto reciente: el framework que has puesto en marcha, el lenguaje y el pipeline en el que corre.
- Incluye un apartado de proyectos si tu empresa te ha dado poca automatizacion. Una suite de pruebas abierta y limpia contra una aplicacion de demostracion sirve, siempre que la describas con exactitud.
- Conserva tus puntos fuertes de tester manual. Quien entiende el riesgo y a los usuarios escribe mejores pruebas automaticas.
Conocimiento del sector y certificaciones
El conocimiento del dominio suele decidir una entrevista de QA. Probar pagos exige entender devoluciones, contracargos y redondeos de divisas. El sector sanitario trae trazabilidad y las exigencias del RGPD sobre datos de salud. Si has trabajado en banca, seguros o sanidad, nombra el sector en la frase bajo tu nombre y en los puntos de experiencia: quien contrata en ese sector lo lee como un periodo de adaptacion corto.
Certificaciones como ISTQB Foundation, gestionada en el pais por el SSTQB, o un nivel avanzado o agil, pueden ayudar, sobre todo en el primer filtro y a menudo en consultoras. Rara vez pesan por encima de la experiencia, asi que basta con una mencion breve. El texto sobre certificaciones en el CV explica su ubicacion; para un tester, la regla principal es no colocar el certificado por encima del trabajo que demuestra que sabes probar.
Si tu perfil de LinkedIn ya detalla tus proyectos y herramientas, una herramienta como Postulit puede convertirlo en un primer borrador de CV, que luego recortas segun el camino elegido al principio.
El siguiente paso
Abre tu CV y toma los tres primeros puntos de tu puesto actual o reciente. Comprueba que cada uno nombra una herramienta o tecnica, una funcionalidad o zona de riesgo, y un resultado que puedas defender en una entrevista. Reescribe cualquier punto que solo diga lo que ejecutas. Para cerrar, relee la frase bajo tu nombre y asegurate de que anuncia con claridad el camino que buscas: QA funcional, automatizacion o SDET.