# Automatización de Pruebas > Un AI Pod con alcance definido que convierte la regresión manual en gates que el pipeline exige en cada merge. 80 a 200 story points. Fuente: https://www.koombea.com/es/ai-pods/catalog/test-automation/ --- La regresión manual es la razón por la que tus releases son mensuales. Este Pod la convierte en escenarios que el pipeline exige, para que lanzar deje de necesitar una persona y una hoja de cálculo. ## El problema La regresión manual pone el techo de qué tan seguido puedes lanzar. Verificar un release cuesta dos días, así que lanzas una vez al mes. Cada release carga entonces un mes de cambios. Los releases grandes fallan más, lo que vuelve a todos más cautelosos, lo que los hace más grandes. Los equipos rompen ese ciclo escribiendo pruebas. Después rompen las pruebas no corriéndolas en cada merge. Una suite que corre de noche y amanece en rojo no es una red de seguridad. Es una notificación que todos silenciaron. Así que construimos gates, no reportes. Un escenario que no bloquea un merge no cambia el comportamiento de nadie. - Cada escenario corre en cada merge, no de noche - Un gate en rojo bloquea el merge, sin excepciones por costumbre - Las pruebas inestables se tratan como defectos y se arreglan, no se reintentan ## Qué entrega este Pod - **Primero los recorridos críticos**: Las rutas que cargan ingresos, automatizadas de punta a punta, porque una suite que cubre todo por igual cubre lo importante demasiado tarde. - **Datos de prueba que no son una persona**: Fixtures y semillas, para que correr la suite no dependa de que alguien se acuerde de resetear un ambiente. - **Gates en el pipeline**: Conectados a CI como verificación obligatoria, con un tiempo de corrida corto para que nadie sienta la tentación de saltarlos. - **Cobertura legible**: Reportes de qué está cubierto y qué no, para que el riesgo restante sea una lista conocida y no un supuesto. ## Por qué importa el orden Los escenarios salen de la especificación, antes de la implementación que verifican. En un producto existente no hay especificación de dónde partir. Así que el primer paso es establecer cuál es el comportamiento actual y confirmarlo contigo. Esa conversación destapa dos o tres comportamientos que nadie quiso y de los que todos ya dependen. ## Dónde va la suite en realidad ## Cuánto cuesta 80 a 200 story points. Lo determinan el número de recorridos críticos y qué tan testeable es la aplicación hoy. Una aplicación con costuras y una interfaz estable es rápida. Una donde todo está soldado a la interfaz hay que despegarla primero. Definimos el alcance desde un recorrido de tu proceso de release actual. Así la estimación refleja la suite que necesitas y no un porcentaje de cobertura que alguien eligió. - Puntos: 80 a 200, comprometidos antes de empezar - Definido desde tu proceso de release, no desde una meta de cobertura - Playwright, Cypress y los frameworks que tu equipo ya corre - La entrega incluye cómo escribir la siguiente ustedes mismos