Introducción — 2.3 “Prueba de mantenimiento”
La “maintenance testing” (prueba de mantenimiento) abarca las actividades de prueba que se realizan después de poner el software en operación o cuando se modifica un elemento ya liberado. Su propósito es controlar el riesgo de cambio: verificar que la corrección o el ajuste cumplan su objetivo (“confirmation testing”) y que no aparezcan efectos colaterales (“regression testing”). La planificación de mantenimiento considera el análisis de impacto (“impact analysis”) para determinar qué probar, dónde y con qué prioridad, según el tipo de mantenimiento (p. ej., correctivo, adaptativo, perfectivo/preventivo) y los activadores del cambio (incidentes en producción, migraciones, parches de seguridad, cambios de entorno o regulatorios, retirada/“sunset”, etc.).
Las pruebas de mantenimiento y sus activadores (K2)
Vista rápida
Idea clave: “Maintenance testing” = probar cambios en software en uso.
Cómo: “confirmation testing” (verifica el fix) + “regression testing” (asegura no romper lo existente) + “impact analysis” (decide el alcance).
Cuándo se activa: incidentes en producción, parches, cambios de entorno/datos, migraciones/actualizaciones, requisitos/regulaciones, “end-of-life”/retirada.
Explicación
La prueba de mantenimiento gestiona el riesgo que introducen cambios sobre sistemas ya liberados. Parte de un activador (“trigger”) —por ejemplo, un incidente en producción, una actualización de plataforma (SO, DBMS, librerías), un parche de seguridad, una migración de datos/infraestructura, la introducción/retiro de funcionalidades o un cambio regulatorio. Ante cada activador, el equipo realiza análisis de impacto para seleccionar niveles y tipos de prueba pertinentes, priorizando por riesgo. El ciclo típico incluye: (1) confirmation testing del fix/cambio puntual, (2) regression testing del entorno afectado (suite crítica automatizada cuando sea posible) y (3) verificación de datos/configuración asociados al cambio.
Aplicabilidad (caso de uso)
Contexto: App de pagos en producción.
Activador: Nueva versión del gateway + parche de seguridad TLS.
Acciones:
- Impact analysis: identificar módulos y rutas críticas (autenticación, captura, liquidación, conciliación).
- Confirmation testing: re-ejecutar el caso que fallaba con el gateway anterior y validar el “handshake” TLS actualizado.
- Regression testing: suite priorizada (autorización, reversa, multi-moneda, reportes), pruebas de compatibilidad con tarjetas y validación de “timeout/latencia” objetivo.
- Cierre: evidencias trazables y monitoreo post-release (métricas de errores/latencia).
Nota de dependencias
- “Maintenance testing” depende de “impact analysis” para ajustar alcance y prioridad.
- Combina sistemáticamente “confirmation testing” (verificar el cambio) con “regression testing” (proteger lo estable).
- Los activadores determinan qué áreas tocar y qué riesgos dominar (p. ej., seguridad/performance ante parches de plataforma, integraciones ante migraciones).
