El cliente es una plataforma de formación en línea con clases interactivas, deberes, áreas personales para alumnos y padres, y pagos en línea. El negocio tiene una fuerte estacionalidad: en septiembre se incorporan más alumnos y una caída de la plataforma durante las primeras semanas del curso significa perder clientes para siempre. No había un equipo de QA interno: los propios desarrolladores probaban el producto entre otras tareas, la regresión previa al lanzamiento duraba tres días y aun así dejaba pasar escenarios críticos como el pago, la reserva de clases y el acceso al aula. El cliente acudió a nosotros tras otro incidente en el que un error en los pagos hizo que la escuela perdiera parte de las solicitudes acumuladas durante el verano.
Implantar desde cero un proceso de aseguramiento de calidad con prioridades basadas en los riesgos de negocio,
automatización de escenarios clave, integración de controles en CI y pruebas de carga antes del pico de septiembre. La condición era trabajar sin detener el desarrollo: los lanzamientos seguían siendo semanales y septiembre no podía esperar.
Empezamos con un análisis de riesgos, no con pruebas automatizadas: identificamos qué escenarios fallaban con más frecuencia y dónde un error tenía el mayor coste. La automatización siguió estrictamente esa lista.
- Auditamos la calidad: analizamos los errores de los últimos seis meses, entrevistamos a los equipos y trazamos los escenarios más problemáticos: pagos, reserva de clases, acceso al aula y notificaciones a los padres.
- Redactamos una estrategia de pruebas con niveles de test, áreas de responsabilidad, criterios de finalización de funcionalidades y procedimientos para informar de errores, comunes a los tres equipos de desarrollo.
- Automatizamos el recorrido crítico: escenarios E2E en Playwright para la plataforma web, pruebas de API para el backend y un conjunto smoke antes de cada lanzamiento.
- Integramos controles de QA en CI: no se puede lanzar una versión si falla el conjunto smoke; la regresión completa se ejecuta cada noche y los resultados están a la vista de todos los equipos en GitLab.
- Realizamos pruebas de carga con k6: simulamos el tráfico del pico de septiembre, encontramos cuellos de botella y los resolvimos con el equipo de backend antes del inicio de temporada.
- Transferimos el proceso al cliente: documentación, procedimientos y formación del ingeniero de QA en las pruebas automatizadas y el pipeline.
La decisión clave fue priorizar según los riesgos de negocio, no según lo «bonito» que pareciera el porcentaje de cobertura. No perseguimos deliberadamente una automatización del 100%: cubrir el 75% de los escenarios críticos aportó la mayor parte del resultado porque protegía justo los recorridos en los que la plataforma gana o pierde clientes. El resto se cubre con pruebas exploratorias manuales antes de los lanzamientos importantes.
El principal efecto económico fue adelantar la detección de defectos: un error que detecta una prueba automatizada en CI cuesta decenas de veces menos que uno que descubre en producción el padre de un alumno. La plataforma llegó a la temporada con un margen de seguridad y los equipos pudieron publicar cambios con frecuencia sin temer el «efecto del viernes». También aumentó la confianza del negocio: el equipo comercial puede prometer con honestidad a las escuelas asociadas una plataforma estable durante el pico de inscripciones.
| Indicador | Resultado |
|---|---|
| Errores críticos en producción | 5–7 al mes → 1–2 por trimestre |
| Regresión previa al lanzamiento | 3 días manualmente → 4 horas con pruebas automatizadas |
| Pico de carga de septiembre | Incidentes cada año → 0 incidentes, sin degradación |
| Momento en que se detecta el defecto | Normalmente en producción → Las pruebas automatizadas lo detectan antes del lanzamiento |
Las métricas se han trasladado de los materiales originales del caso. El período se indica cuando está especificado en la fuente.
- errores críticos por trimestre (antes, 5–7 al mes)
- 1–2
- regresión con pruebas automatizadas (antes, 3 días manualmente)
- 4 h
- de los escenarios clave cubiertos por pruebas automatizadas
- 75%
- incidentes durante el pico de septiembre
- 0
Escala ilustrativa: 3 días se convierten en 72 horas. Para la longitud de las barras, el rango mensual de errores se escala a un trimestre multiplicándolo por tres; se comparan los límites superiores.
- 01Commit
- 02Conjunto smokeSi el smoke no pasa, no hay lanzamiento
- 03Lanzamientosemanal
- 04Ejecución nocturnaregresión completa
Próximos pasos que recomendamos para la plataforma:
- Pruebas de regresión visual: comprobación automatizada del diseño de las clases, correos electrónicos y áreas personales.
- Fábrica de datos de prueba: generación de alumnos, grupos y pagos realistas para cada ejecución.
- QA en producción: feature flags y lanzamientos canarios para activar nuevas funciones gradualmente.
Dejamos de tener miedo a los lanzamientos. Antes, cualquier viernes podía acabar en una revisión de quejas; ahora, publicar en producción es una rutina de quince minutos.
— CTO de la escuela en línea