regression-check

name	regression-check
description	Usar para verificar que cambios nuevos no rompen funcionalidad existente. También: algo se ha roto, cambio rompe funcionalidad, verificar que no hay regresión, tests de regresión.

Verificación de regresiones

Resumen

Este skill verifica que los cambios recientes no han roto funcionalidad que antes funcionaba correctamente. Las regresiones son uno de los tipos de bug más frustrantes: algo que el usuario daba por hecho deja de funcionar sin razón aparente. Este proceso las detecta antes de que lleguen a producción.

El enfoque es sistemático: se analiza el impacto del cambio, se ejecutan los tests relevantes y se verifica la integración con el resto del sistema.

Proceso

1. Analizar el alcance del cambio. Entender qué se ha modificado:

   • Ficheros cambiados (diff de Git).
   • Módulos afectados directamente.
   • Dependientes: qué otros módulos importan o usan los módulos cambiados.
   • Interfaces públicas: se ha cambiado alguna firma de función, tipo de retorno o contrato?

2. Mapear las áreas de impacto potencial. Un cambio en un módulo base puede afectar a todo lo que depende de él. Trazar el árbol de dependencias hacia arriba:

   Módulo cambiado --> Módulos que lo importan --> Módulos que importan a esos
   

   Cuanto más profundo en el árbol, mayor es el área de impacto.

3. Ejecutar los tests del área afectada. En orden:

   • Tests unitarios de los módulos modificados.
   • Tests unitarios de los módulos dependientes.
   • Tests de integración que cubran la interacción entre módulos afectados.
   • Tests e2e de los flujos que pasan por los módulos afectados.

4. Si hay tests que fallan, analizar la causa:

   • El test falla porque el cambio rompe una funcionalidad existente? Es una regresión real. Corregir.
   • El test falla porque su expectativa era incorrecta y el cambio es correcto? Actualizar el test con justificación.
   • El test es inestable (flaky) y falla intermitentemente? Documentar y marcar para arreglar.

5. Identificar lagunas de testing. Si hay áreas afectadas por el cambio que no tienen tests:

   • Documentar la laguna como riesgo.
   • Si el riesgo es alto, escribir tests de caracterización antes de dar el cambio por bueno.
   • Crear issues para cubrir las lagunas detectadas.

6. Verificar integración. Más allá de los tests automatizados, verificar manualmente o con tests exploratorios que los flujos principales siguen funcionando. Prestar especial atención a:

   • Flujos que cruzan múltiples módulos.
   • Integraciones con servicios externos.
   • Comportamiento en condiciones de error.

7. Documentar el resultado. Registrar: qué se verificó, qué pasó, qué quedó sin verificar y por qué.

Criterios de éxito

• Se ha analizado el impacto del cambio en todo el árbol de dependencias.
• Los tests del área afectada se han ejecutado y pasan.
• Los tests que fallan han sido analizados y clasificados (regresión real, test incorrecto, flaky).
• Las lagunas de testing están documentadas con su nivel de riesgo.
• No hay regresiones reales sin corregir.