El QA clásico tiene los días contados: qué ha pasado con el testing

Casos de prueba, regresión, cobertura: son las herramientas en las que la industria del QA ha confiado durante décadas. Parecían universales: escribes las comprobaciones, las ejecutas antes del lanzamiento y te aseguras de que nada se ha roto. Pero este modelo se desmorona en el contexto actual del desarrollo, donde las releases continuas, los microservicios y los sistemas en la nube se han convertido en la norma.

Cómo ha cambiado radicalmente el desarrollo

Hubo un tiempo en que las empresas lanzaban nuevas versiones de su producto una vez por trimestre o por semestre. Los testers trabajaban en cascada: el desarrollador escribe el código, QA lo verifica y después llega el despliegue. Hoy Uber, Netflix y Spotify hacen entre 10 y 100 despliegues al día. Los cambios llegan a producción varias veces por hora.

La arquitectura ha cambiado por completo. Los monolitos se han fragmentado en microservicios que funcionan sobre infraestructura en la nube. Los recursos se crean y se eliminan bajo demanda. Ha surgido una nueva clase de problemas: fallos de red, desincronización entre servicios y pérdida de datos en transacciones distribuidas.

Y en ese mismo periodo, los componentes de IA entraron en los sistemas. Por naturaleza son no deterministas: una misma entrada puede producir salidas distintas. ¿Cómo se prueba algo que se comporta de forma impredecible?

Por qué se ha roto el enfoque clásico

El problema no está en las pruebas en sí ni en la pereza de los equipos de QA. El problema es el modelo en su conjunto.

Los casos de prueba requieren actualizarse constantemente, pero la funcionalidad crece más rápido de lo que las pruebas pueden seguir. Esto genera un retraso acumulado y una falsa sensación de seguridad.

La métrica de cobertura de código se ha convertido en un fin en sí misma en lugar de una herramienta. Un 100% de cobertura no garantiza la ausencia de bugs: solo indica que se han ejecutado todas las líneas de código.

Las pruebas de regresión exigen un crecimiento exponencial del tiempo: con cada nueva funcionalidad hay que verificar todo lo anterior más lo nuevo. En unos pocos años, esto se vuelve inasumible.

La aceptación previa al lanzamiento se ha convertido en un cuello de botella. Ralentiza el ciclo y se convierte en un punto de fallo. La automatización ayudó, pero creó un nuevo problema: los scripts se rompen con cada cambio en la interfaz o en la API.

Qué viene a sustituirlo

En lugar de las pruebas estáticas en laboratorio, las empresas adoptan enfoques que se ajustan a la realidad del desarrollo:

• Pruebas de contrato: los microservicios verifican entre sí la coherencia de los contratos de API
• Chaos engineering: los ingenieros rompen el sistema a propósito para comprobar su tolerancia a fallos
• Observabilidad y monitorización: detección de problemas en producción a partir de métricas y logs
• Feature flags: despliegue gradual de nuevas funciones y reversión en segundos
• Continuous testing en producción: verificación con datos reales y usuarios reales

El cambio de paradigma es evidente: antes, las pruebas ocurrían al principio del ciclo, antes del lanzamiento. Ahora continúan en producción. El despliegue no es el final del ciclo de verificación, sino el comienzo.

Qué significa esto

QA deja de ser un guardia fronterizo y pasa a ser un ingeniero que gestiona riesgos en producción. Esto exige reciclarse: en lugar de saber escribir casos de prueba, hacen falta conocimientos de monitorización, ingeniería de fiabilidad y arquitectura de microservicios. La IA no tiene la culpa: simplemente ha acelerado lo inevitable.