Cómo pasarse a QA desde otra profesión

Qué se transfiere realmente

Si has trabajado en atención al cliente, ya sabes reproducir un problema, hacer las preguntas de seguimiento adecuadas y anotar los pasos con suficiente claridad para que otra persona los repita. Eso es casi todo lo que es un informe de error. Si has enseñado, redactado procedimientos o hecho cualquier tipo de trabajo de cumplimiento normativo o auditoría, ya piensas en términos de «qué podría salir mal aquí y cómo lo comprobaría». Ese instinto es el trabajo real, más que cualquier herramienta.

El conocimiento del sector se transfiere directamente. Si has pasado cinco años en seguros, administración sanitaria o logística y vas a probar software construido para ese sector, ya entiendes las reglas de negocio que un tester genérico tendría que aprender desde cero: qué nunca debería permitirse hacer con una reclamación, qué estado de envío no se puede saltar. Los reclutadores en sectores regulados o complejos sí se fijan en esto, porque acorta la incorporación.

Participar en pruebas de aceptación de usuario (UAT) desde el lado del negocio, incluso de manera informal, está más cerca de QA de lo que la gente cree. Si alguna vez has dado el visto bueno a una versión, presentado tickets contra un proveedor o ejecutado un script de prueba escrito por otra persona, dilo explícitamente: es evidencia, no solo interés.

Lo que no se transfiere es la suposición de que las pruebas consisten simplemente en «usar el software y fijarse en las cosas». Eso es testing exploratorio, y es una técnica entre varias, no la disciplina. La ingeniería de QA también significa escribir casos de prueba estructurados, diseñar cobertura mediante métodos como partición de equivalencia y análisis de valores límite y, cada vez más, escribir comprobaciones automatizadas en código. Nada de eso viene de la experiencia adyacente. Hay que construirlo.

Qué necesitas construir realmente

Un anuncio de empleo de QA moderno, incluso a nivel de entrada, normalmente listará alguna combinación de: un rastreador de bugs (Jira es el común), una herramienta de gestión de pruebas, SQL para comprobar lo que la aplicación realmente escribió en la base de datos y un framework de automatización: Selenium, Cypress o Playwright, desde Java, Python o JavaScript. Muchos también mencionan pruebas de API con Postman, y algunos mencionan pruebas de rendimiento con JMeter o pruebas de accesibilidad contra WCAG.

No necesitas todo esto antes de presentarte. Necesitas lo suficiente para sobrevivir un cribado técnico y tener algo a lo que señalar. En la práctica eso significa:

• Escribe casos de prueba y un plan de pruebas para un software real (tu propio proyecto, una herramienta de código abierto, cualquier cosa con comportamiento visible) y ponlo en algún sitio revisable.
• Aprende una herramienta de automatización bien en lugar de varias mal. Playwright y Cypress son actualmente las que más anuncios nuevos piden en entornos con mucho JavaScript; Selenium con Java sigue siendo común en stacks empresariales más antiguos.
• Aprende suficiente SQL como para escribir un join y un filtro. El trabajo de QA implica comprobar datos, no solo hacer clic en botones.
• Familiarízate con el vocabulario: regression testing, smoke testing, cobertura de pruebas, gravedad del defecto frente a prioridad, la idea de shift-left de probar antes en el desarrollo en lugar de al final. Los entrevistadores usan este lenguaje sin definirlo, y no conocerlo se lee como no haber hecho el trabajo.

Si vienes de un campo técnico —ingeniería de soporte, análisis de datos, incluso una formación parcial en informática— el lado de la automatización avanzará más rápido porque la programación no es nueva, solo su aplicación. Si vienes de un campo no técnico, sé honesto contigo mismo de que esta es la parte lenta, y reserva meses reales para ello, no un curso de fin de semana.

¿Hay alguna licencia o titulación que necesites?

No. Ingeniero de QA no es un título regulado ni colegiado en ningún sitio al modo en que, digamos, un contador o un electricista sí lo es. Nadie comprueba un registro antes de que se te permita trabajar.

Lo más parecido a una credencial reconocida en la industria es el certificado ISTQB Foundation Level, emitido por el International Software Testing Qualifications Board a través de juntas nacionales miembro. Cubre el vocabulario estándar y las técnicas de testing y es genuinamente común verlo referenciado en anuncios de empleo, particularmente en Europa y en organizaciones más grandes y con más procesos.

Si vale la pena hacerlo es discutido, y deberías conocer ambos lados en lugar de aceptar un veredicto por fe. A su favor: te da el vocabulario compartido rápido, es una línea concreta en un CV que responde a la pregunta «¿saben lo que realmente es el testing?», y algunos empleadores lo usan como filtro de cribado, así que tenerlo te hace pasar un match de palabras clave de ATS que de otro modo fallarías. En contra: muchos testers experimentados y responsables de contratación lo consideran una credencial de papel que prueba que puedes aprobar un examen tipo test, no que puedes probar software, y lo dirán si te apoyas demasiado en ello en una entrevista en lugar de mostrar trabajo real.

Una posición razonable: si aún no tienes otra evidencia de conocimiento de testing, haz el examen ISTQB Foundation pronto —son unas pocas semanas de estudio— y luego dedica la mayor parte de tu esfuerzo a un portafolio que demuestre que puedes hacer la cosa, no solo definirla.

Qué tiene que superar realmente tu candidatura

Dos problemas se superponen para alguien en reconversión, y son problemas diferentes.

El primero es el sistema de seguimiento de candidatos. Los anuncios de empleo para roles de QA nombran cada vez más herramientas específicas y años de experiencia con ellas —«3+ años con Selenium», «experiencia con Cypress y pipelines de CI/CD»— y un ATS a menudo filtrará por coincidencias exactas de palabras clave antes de que una persona vea el CV. Si tu CV no contiene los nombres de las herramientas del anuncio porque genuinamente no las has usado todavía, ninguna cantidad de encuadre de competencias transferibles te hace pasar esa etapa. Este es un filtro mecánico real, no una metáfora, aunque la agresividad con la que el sistema de cualquier empleador lo aplica varía y no es algo que puedas verificar desde fuera.

El segundo es el humano, una vez pasado ese filtro: un responsable de contratación mirando tu CV y necesitando responder «¿puede esta persona encontrar bugs y escribir un caso de prueba sin supervisión pesada para el mes dos?». Un CV de reconversión sin títulos de trabajo en QA tiene que responder esa pregunta con evidencia en lugar de afirmación —el portafolio, un proyecto específico, un bug específico que encontraste y cómo lo documentaste— porque tu historial laboral no lo responderá por ti.

La solución práctica para ambos es la misma: pon las herramientas y técnicas nombradas del anuncio en el primer tercio de tu CV o candidatura, respaldadas por algo real, no solo listadas como «familiarizado con». Una descripción de proyecto de una línea —«escribí y automaticé 40 casos de prueba de regresión para una app Django usando Playwright y Python, encontré y presenté 12 defectos»— hace más trabajo que un punto afirmando atención al detalle.

El calendario honesto

Hay dos rutas separadas aquí, y toman cantidades de tiempo muy diferentes.

Testing manual y funcional, sin automatización, es la puerta más rápida. Si puedes construir un portafolio pequeño pero real —un par de planes de prueba, un writeup de búsqueda de bugs, ISTQB Foundation— y te presentas para roles de analista de pruebas junior o analista de QA en lugar de "ingeniero de QA" propiamente dicho, algunas personas se pasan en unos pocos meses, especialmente si pueden conseguir primero un título adyacente a QA internamente en su empleador actual, lo que evita completamente el problema del CV.

Ingeniería de QA con capacidad de automatización es una ruta más larga, y deberías tratarla como aprender a programar con un propósito específico, no una habilidad ligera para adquirir de paso. Llegar al punto donde puedes escribir una suite de pruebas automatizada mantenible, depurar pruebas inestables y hablar con credibilidad sobre integrar pruebas en un pipeline de CI/CD comúnmente lleva la mayor parte de un año de práctica constante para alguien sin formación en programación —a veces más si lo haces alrededor de un trabajo a tiempo completo.

También vale la pena decirlo claramente: el mercado ha cambiado. Los roles de testing puramente manual sin ninguna expectativa de automatización están encogiéndose mientras las empresas empujan la responsabilidad del testing antes en el desarrollo, y una porción creciente de anuncios de "QA junior" ya listan un lenguaje de scripting como requisito, no como algo deseable. Eso no cierra la ruta, pero sí significa que el camino solo-manual es una puerta más estrecha de lo que solía ser, y vale la pena dirigir tu tiempo de estudio a la automatización desde temprano en lugar de tratarla como una etapa dos a la que llegarás eventualmente.

Qué hacer a continuación

Elige una herramienta de automatización y un pequeño proyecto real, y construye la pieza de portafolio antes de enviar otra candidatura: un CV que reclama habilidades de QA sin nada que mostrar por ellas es lo que se está filtrando ahora mismo, no tu falta de un título de trabajo en QA. Haz ISTQB Foundation si no tienes otra credencial a la que señalar. Luego vuelve a los anuncios de empleo por los que ya te han rechazado y comprueba, herramienta por herramienta, si tu CV realmente contenía las palabras por las que estaban filtrando.

jobmarket.pro lee cada anuncio completo y prepara una candidatura desde tu historial laboral real, casándola con lo que el anuncio genuinamente pide en lugar de adivinar palabras clave.