Title: Actividad 9: Pruebas de Regresión
Course: 2025 - LI - Pruebas de Software 3-1 y 3-2 > Section: Unidad 2 - Ingeniería de pruebas y planificación

Objetivo

Comprender qué son las pruebas de regresión, cuándo aplicarlas, cómo priorizarlas y seleccionarlas tras cambios en el software, y proponer una mini–estrategia de regresión para un caso práctico.

Instrucciones

1. Identificación
En la parte superior del documento escribe tu nombre completo y el nombre del profesor.
2. Conceptos clave (breve y con tus palabras)
  - ¿Qué es una prueba de regresión y cuál es su propósito?
  - ¿Cuándo se ejecutan? (ej.: correcciones de bugs, refactors, nuevas features, actualizaciones de dependencias).
  - Diferencia entre retesting y regresión.
3. Tipos y enfoques de regresión (resumen breve)
Explica en 1–2 líneas cada uno (con tus palabras):
  - Selective/Impact-based (seleccionar casos afectados por el cambio)
  - Partial (subconjunto crítico)
  - Retest-all (todo el suite)
  - Correctiva vs. Progresiva (según cambios en el conjunto de pruebas)
4. Caso práctico (planeación sin código)
Imagina una app web con módulos: Login, Catálogo, Carrito, Pago, Reportes.
Cambios recientes:
  - Se refactorizó la validación de Login.
  - Se cambió el cálculo de descuentos en Carrito.
  - Se actualizó la librería de gráficos usada en Reportes.
Con base en esto:
a) Elabora una matriz de impacto (tabla simple) mapeando cambios → módulos impactados directos/indirectos.
b) Propón un conjunto de pruebas de regresión priorizado (Alta / Media / Baja) indicando qué probarías en cada módulo y por qué.
c) Distingue retesting (del bug o cambio puntual) vs regresión (efectos colaterales) dentro de tu plan.
d) Define un criterio de salida (cuándo considerar la regresión “aprobada”).
5. Priorización por riesgo (breve)
En 5–6 líneas, explica cómo priorizarías casos: impacto en negocio, frecuencia de uso, criticidad (ej.: Pago > Carrito > Login > Catálogo > Reportes si aplica), historial de fallos, complejidad técnica.
6. Automatización (alto nivel)
  - ¿Qué subconjunto automatizarías para la regresión continua y por qué?
  - ¿Cada cuánto se debe ejecutar la regresión automatizada (ej.: en cada build principal, nightly, antes de releases)?
(No pidas herramientas; solo criterio y alcance.)
7. Formato sugerido de casos (plantilla breve, 2–3 ejemplos)
Incluye 2–3 casos de regresión (sin código) usando esta plantilla mínima:
  - ID / Módulo / Precondiciones / Pasos / Resultado esperado / Prioridad

Evidencia

- Documento con: conceptos (punto 2), tipos (punto 3), caso práctico con matriz de impacto y plan priorizado (punto 4), priorización por riesgo (punto 5), propuesta de automatización (punto 6) y 2–3 casos de ejemplo (punto 7).
- Entrega en PDF.

Método de entrega

Sube tu PDF a la plataforma.

Objetivo

Comprender qué son las pruebas de regresión, cuándo aplicarlas, cómo priorizarlas y seleccionarlas tras cambios en el software, y proponer una mini–estrategia de regresión para un caso práctico.

Instrucciones

1. Identificación
En la parte superior del documento escribe tu nombre completo y el nombre del profesor.
2. Conceptos clave (breve y con tus palabras)
  - ¿Qué es una prueba de regresión y cuál es su propósito?
  - ¿Cuándo se ejecutan? (ej.: correcciones de bugs, refactors, nuevas features, actualizaciones de dependencias).
  - Diferencia entre retesting y regresión.
3. Tipos y enfoques de regresión (resumen breve)
Explica en 1–2 líneas cada uno (con tus palabras):
  - Selective/Impact-based (seleccionar casos afectados por el cambio)
  - Partial (subconjunto crítico)
  - Retest-all (todo el suite)
  - Correctiva vs. Progresiva (según cambios en el conjunto de pruebas)
4. Caso práctico (planeación sin código)
Imagina una app web con módulos: Login, Catálogo, Carrito, Pago, Reportes.
Cambios recientes:
  - Se refactorizó la validación de Login.
  - Se cambió el cálculo de descuentos en Carrito.
  - Se actualizó la librería de gráficos usada en Reportes.
Con base en esto:
a) Elabora una matriz de impacto (tabla simple) mapeando cambios → módulos impactados directos/indirectos.
b) Propón un conjunto de pruebas de regresión priorizado (Alta / Media / Baja) indicando qué probarías en cada módulo y por qué.
c) Distingue retesting (del bug o cambio puntual) vs regresión (efectos colaterales) dentro de tu plan.
d) Define un criterio de salida (cuándo considerar la regresión “aprobada”).
5. Priorización por riesgo (breve)
En 5–6 líneas, explica cómo priorizarías casos: impacto en negocio, frecuencia de uso, criticidad (ej.: Pago > Carrito > Login > Catálogo > Reportes si aplica), historial de fallos, complejidad técnica.
6. Automatización (alto nivel)
  - ¿Qué subconjunto automatizarías para la regresión continua y por qué?
  - ¿Cada cuánto se debe ejecutar la regresión automatizada (ej.: en cada build principal, nightly, antes de releases)?
(No pidas herramientas; solo criterio y alcance.)
7. Formato sugerido de casos (plantilla breve, 2–3 ejemplos)
Incluye 2–3 casos de regresión (sin código) usando esta plantilla mínima:
  - ID / Módulo / Precondiciones / Pasos / Resultado esperado / Prioridad

Evidencia

- Documento con: conceptos (punto 2), tipos (punto 3), caso práctico con matriz de impacto y plan priorizado (punto 4), priorización por riesgo (punto 5), propuesta de automatización (punto 6) y 2–3 casos de ejemplo (punto 7).
- Entrega en PDF.

Método de entrega

Sube tu PDF a la plataforma.