QA en 2026: pánico o evolución
Llegas al all-hands de la empresa: se anuncia que hay que reducir gastos ya que los ingresos no son los esperados: menos viajes, CEO vigilando los gastos, salarios congelados.
Semanas después, otra reunión: las medidas anunciadas previamente no son suficientes. Ahora entran en la conversación palabras como ERE, despido, o reestructuración.
Eres QA. Aparece el nerviosismo como el que más.
Si esto te suena, no estás solo. Según el último Tech Career Report 2025 de Manfred, QA & Testing es una de las posiciones más castigadas de los últimos años: menos ofertas, salarios a la baja. Y la llegada de la IA solo acelera la tendencia.
Pero el dato es la consecuencia, no la causa. Debajo hay problemas reales que llevamos años ignorando, y que ahora nos están pasando factura. La buena noticia: con algunos cambios de enfoque, podemos cambiar la percepción que se tiene de nosotros.
Nadie sabe qué somos ni qué hacemos
QA Tester. QA Engineer. QA Automation. QE. Quality Coach. SDET, … y sigue añadiendo los que se te ocurran. Cada empresa nos llama como quiere. A veces por hype, a veces porque un título chulo atrae mejor talento. Y si lo hemos leído de una empresa americana, mejor que mejor.
Pero el problema no son los títulos: es que cada empresa interpreta el rol y qué hace QA a su manera. En unas eres quien rompe cosas antes de producción. En otras, una columna en Jira llamada "ready for QA" (o peor: con tu nombre directamente). En otras, eres "el de calidad", pero nadie sabe muy bien qué haces ahí. O el que automatiza los tests. Y los diferentes contextos e interpretaciones no son malos, pero generan discursos diferentes, y a veces contradictorios.
Y aquí os lanzo una pregunta que yo mismo me hago: ¿lo tenemos claro nosotros mismos?
Testing ≠ Calidad
Antes de seguir, pensemos: ¿Qué tiene más calidad: la mesa de Ikea de 9,99 € que millones de personas tienen en casa o un Ferrari de 200.000 € que conducen unos pocos miles?
Casi todos diríamos "el Ferrari" sin pensarlo. Y en parte es cierto. Pero pensemos en la mesa: cumple exactamente lo que promete: aguantar lo que le pongas encima, costar poco y montarse en menos de 10 minutos. Eso también es calidad.
Calidad no es precio. No es lujo. No es la ausencia de errores. Pero seguimos pensando que un producto es de calidad cuando no tiene errores. Y aquí entra, el principal problema: ¿por qué le llamamos calidad cuando queremos decir testing? Y viceversa. Son cosas distintas, aunque las usamos como sinónimos.
- Testing: Es una actividad: se valida que el producto hace lo que tiene que hacer. Ejecutando casos de prueba, encontrando bugs.
- Calidad: Es una propiedad: del producto, del proceso, de cómo trabajamos, de la experiencia del usuario, del impacto en negocio, de la cultura y de la forma de trabajar en la empresa. Es una propiedad transversal y global.
Confundirlas es el origen de casi todos los problemas que vienen después. Como me dijo un buen amigo: “Testing ≠ Calidad, pero la calidad incluye testing”
Todos predican por la calidad. Pocos la practican.
Te contratan como experto para aportar valor. Los primeros días hablas con tech leads, desarrolladores, producto. Todo marcha bien. Todos quieren un producto de calidad, todos quieren involucrarse. La alineación parece clara.
Pasan las semanas. Y sigues siendo el único que testea las releases, el único que automatiza, el único que genera las métricas que te pidieron definir pero que nadie mira (o que rechazan porque siguen exigiendo cobertura de tests, esa métrica de vanidad que sin contexto no aporta nada).
Pasan los meses. Sigues testeando, automatizando, abriendo bugs. Cuando insistes en cambiar algo, te dicen que en este momento el negocio necesita exactamente lo que estás haciendo.
Compromiso de palabra: mucho. Compromiso real para cambiar la mentalidad/forma de trabajar/cultura : poco.
El problema de mirarse el ombligo
Miremos un equipo de producto. Cada rol mide lo suyo:
- Negocio → dinero y usuarios .
- Producto → features entregadas.
- Desarrollo → tickets cerrados, velocidad, tiempo de desarrollo.
- Testing → tests ejecutados, tests automatizados, bugs encontrados.
¿Y quién mira la calidad del conjunto? ¿Quién se pregunta si lo que se entrega vale, aporta valor a nuestro usuario y a la empresa? Nadie. Y es aquí donde QA tiene que dar un paso al frente y liderar esa transversalidad. Responsabilidad compartida, sí, con QA liderando.
Lo que un QA debe hacer y pocas veces hacemos
Si calidad es lo definido previamente, un QA no es "quien testea". O no solo. Un QA debería trabajar en tres frentes:
Entender el negocio. ¿Sabes cuánto factura tu empresa? ¿Sabes su churn? ¿Sabes cuánto dinero se pierde por cada hora que el producto está caído? Si has respondido "no" a cualquiera de las tres, ese es exactamente el motivo por el que en negocio no nos escuchan.
Entender el sistema. Cómo se construye el producto, dónde se rompe la cadena, cómo fluye la información entre roles y departamentos. Hacer preguntas incómodas. Testear, por supuesto. Y conocer la parte técnica también: estrategia, shift-left, validación, procesos.
Entender al usuario. Como persona, no como ente abstracto. Y traducir lo que le pasa a esa persona en el día a día del equipo.
No sólo somos quien clica botones o automatiza tests. Somos quién debe liderar la importancia de la calidad y el testing.
¿Hablamos el idioma del negocio?
Cuando el CTO o el CEO pregunta "¿cómo va la calidad?" y respondemos:
"Hemos ejecutado 450 tests cases, 200 de ellos automatizados. Hay 23 bugs abiertos y 12 críticos resueltos en este sprint"
¿De verdad creemos que les importa? ¿Que lo entienden siquiera? A negocio le importa otra cosa:
- ¿Vamos a perder clientes por un bug en producción?
- ¿El time-to-market está en riesgo?
- ¿Estamos gastando dinero y tiempo arreglando cosas que podríamos haber evitado?
- ¿La gente confía en lo que sacamos?
Si los QAs solo hablamos con otros roles en métricas de QAs, no nos entienden. Y si no nos entienden, somos gasto. No inversión. Y el gasto se recorta.
La pregunta
Pregúntale a tu product manager, a tu tech lead, a tu CEO:
¿Qué es calidad en nuestro producto?
A ver qué responden. A ver si responden parecido. Spoiler: no lo harán.
Aquí, justo aquí, empieza nuestro trabajo real.
Y ahora volvamos al principio. A esa reunión. A ese nerviosismo. La próxima vez que se hable de recortes o situaciones donde se pueda poner en duda nuestro trabajo, lo que decidirá nuestro futuro no será cuántos tests automatizamos o cuántos bugs encontremos. Será si alguien en el negocio puede explicar, sin nosotros delante, por qué nuestro trabajo importa.
¿Quieres saber un poco más sobre quién ha escrito este artículo? 👇
Ingeniero de calidad con 20 años de experiencia creando equipos de QA. Especialista en automatización, CI/CD y estrategia de calidad integrada desde el inicio del desarrollo.