Hola mi amigo y amiga de la calidad y colegas del mundo del desarrollo. Este es un tema que he visto repetirse muchas veces en distintas empresas, y que normalmente empieza con una muy buena intención: “necesitamos automatizar más nuestras pruebas”. Hasta ahí todo bien, el problema viene en cómo se intenta resolver.

Déjame comenzar con una pregunta que puede parecer simple, pero que dice mucho sobre cómo está diseñado un equipo: ¿quién está escribiendo las pruebas automatizadas en tu proyecto? En muchas organizaciones, la respuesta es clara: hay un equipo especializado, o incluso una persona dedicada únicamente a automatizar pruebas. Y aunque esto suena organizado, eficiente e incluso profesional, en la práctica suele generar más problemas de los que resuelve.

¿Por qué parece buena idea tener un equipo de automatización separado?

Si lo miras desde afuera, tiene sentido. El desarrollo avanza, alguien más se encarga de automatizar, y así el equipo “no se detiene”, porque tienes a alguien probando manualmente y verificando que el trabajo esta siendo entregado “sin errores”. No se interrumpe el ritmo de entrega, y al mismo tiempo se construye una base de pruebas que supuestamente mejorará la calidad del producto.

Pero aquí es donde vale la pena detenerse un momento y pensar: ¿qué tipo de feedback está recibiendo el desarrollador en ese modelo? Si el código se escribe hoy y las pruebas se automatizan días después por otra persona, el feedback ya no es inmediato. Para cuando aparece un problema, el código probablemente ya cambió, otras personas intervinieron y el contexto original se perdió. Lo que parecía eficiencia termina convirtiéndose en retrabajo y coordinación innecesaria.

¿Qué ocurre cuando separas desarrollo y automatización?

En Fifty Quick Ideas to Improve Your Tests se explica algo que, cuando lo lees, tiene todo el sentido del mundo: separar la automatización del desarrollo introduce retrasos, duplicación de trabajo y cuellos de botella. Pero más allá de lo técnico, introduce un problema cultural mucho más serio.

Cuando los desarrolladores saben que alguien más automatizará las pruebas, dejan de diseñar pensando en testabilidad. No porque no les importe la calidad, sino porque el sistema les dice que no es su responsabilidad directa. Y cuando eso ocurre, empiezas a ver código difícil de probar, dependencias acopladas, falta de hooks de testing y, en general, un sistema que obliga a probar todo desde afuera.

El resultado es casi inevitable: pruebas end-to-end lentas, frágiles y costosas de mantener.

¿Por qué los equipos de automatización se convierten en un cuello de botella?

Aquí hay algo que he visto repetirse muchas veces. Un equipo de desarrollo puede producir cambios constantemente, pero una o dos personas encargadas de automatizar no pueden seguir ese ritmo. La capacidad de generar código siempre supera la capacidad de automatizar cuando está centralizada en pocas manos.

Entonces el pipeline comienza a depender de esa velocidad. O se vuelve lento porque espera a que todo esté automatizado, o se vuelve riesgoso porque se decide avanzar sin pruebas completas. Y en ambos casos, el equipo pierde algo importante: o pierde velocidad o pierde calidad.

Además, muchas veces estos equipos utilizan herramientas o lenguajes que el resto del equipo no domina, lo que dificulta la colaboración. Si algo falla en la automatización, no cualquiera puede investigarlo, y eso refuerza aún más el cuello de botella.

¿Por qué esto termina afectando tu pipeline?

Un pipeline sano depende de feedback rápido y confiable. Pero cuando la automatización está desacoplada del desarrollo, ese feedback llega tarde. Las pruebas tardan más en ejecutarse, los errores se detectan cuando ya es más costoso corregirlos y, poco a poco, el equipo deja de confiar en los resultados.

En lugar de ser una herramienta que protege la calidad, el pipeline se convierte en una carga. Algo que “hay que esperar” o incluso algo que algunos intentan evitar. Y cuando eso ocurre, el problema ya no es técnico, es estructural.

Entonces, ¿quién debería automatizar?

Aquí es donde viene la parte que puede incomodar a algunos equipos, pero que es consistente con lo que proponen tanto Fifty Quick Ideas to Improve Your Tests como lo que hemos visto en modelos como Google: los desarrolladores deberían ser responsables de automatizar las pruebas relacionadas con el código que escriben.

No significa que QA desaparezca, ni mucho menos. Significa que el rol cambia. QA deja de ser quien automatiza todo y pasa a ser quien ayuda a definir qué probar, cómo pensar los escenarios, cómo identificar riesgos y cómo diseñar mejor el sistema para que sea testeable.

Cuando los desarrolladores escriben sus propias pruebas, ocurre algo interesante: el feedback es inmediato, las pruebas suelen ser más rápidas porque conocen los internals del sistema y el diseño comienza a mejorar porque se piensa en cómo probar desde el inicio.

¿Qué cambia cuando el equipo asume la automatización?

Cambia más de lo que parece. El sistema se vuelve más modular porque es más fácil probar partes aisladas. Las pruebas dejan de depender exclusivamente de flujos completos y comienzan a aparecer más pruebas pequeñas y medianas que ejecutan rápido. El pipeline deja de ser un cuello de botella y se convierte en una herramienta que da confianza.

Pero quizás lo más importante es que cambia la conversación. Ya no se trata de “quién automatiza”, sino de “cómo construimos algo que sea fácil de probar”. Y esa es una conversación mucho más madura.

Mi recomendación para finalizar

Si hoy tienes un equipo de automatización separado, no significa que todo esté mal. Pero sí vale la pena preguntarte si ese modelo está ayudando o está generando fricción. En lugar de pensar en quién se encarga de automatizar, te invito a pensar en cómo puedes acercar esa responsabilidad al desarrollo sin perder la visión que aporta QA.

Y aquí quiero cerrar con algo que también he aprendido trabajando con distintos equipos: más que supervisar el trabajo de los desarrolladores, lo que realmente genera impacto es conversar con ellos, hacer preguntas, explorar escenarios juntos y ayudar a que piensen en cómo probar lo que están construyendo. Esto no solo mejora la calidad, también mejora el diseño del sistema.

Porque al final, automatizar no es una tarea aislada. Es una consecuencia de cómo piensas cuando construyes software.

Recurso práctico

Checklist: ¿Tu automatización está generando un cuello de botella?

1. Responsabilidad

• ¿Quién escribe las pruebas automatizadas?
• ¿El desarrollador o un equipo separado?

2. Feedback

• ¿Cuánto tiempo pasa entre escribir código y detectar un error?
• ¿Minutos, horas o días?

3. Velocidad del pipeline

• ¿El pipeline es rápido y confiable?
• ¿O el equipo evita ejecutarlo?

4. Tipo de pruebas

• ¿La mayoría son end-to-end?
• ¿O tienes suficientes pruebas pequeñas y rápidas?

5. Colaboración

• ¿Todo el equipo entiende la automatización?
• ¿O depende de pocos especialistas?

Si varias respuestas apuntan a dependencia de un equipo separado, probablemente no tienes un problema de herramientas… sino de cómo estás distribuyendo la responsabilidad.