Entremos en tema
El Syllabus establece que los niveles de prueba organizan el trabajo de verificación y validación según el objeto bajo prueba y el momento en el ciclo de vida. Distinguirlos permite definir objetivos claros, responsabilidades y evidencias trazables. En términos generales, se reconocen cuatro niveles: “component testing” (prueba de componente), enfocado en unidades aisladas; “integration testing” (prueba de integración), centrado en interfaces e interacciones entre componentes o sistemas; “system testing” (prueba de sistema), que verifica el comportamiento extremo a extremo frente a requisitos; y “acceptance testing” (prueba de aceptación), que confirma la idoneidad para uso y los criterios de aceptación. Comprender estas diferencias es esencial para diseñar matrices de cobertura coherentes, optimizar el esfuerzo según riesgo, evitar solapamientos o huecos y alinear la ejecución de pruebas con los objetivos de cada entrega dentro del ciclo de desarrollo.
1) Distinguir los diferentes niveles de prueba (K2)
Los niveles de prueba estructuran el “dónde” y “cuándo” probar: “component testing” (prueba de componente), “integration testing” (prueba de integración), “system testing” (prueba de sistema) y “acceptance testing” (prueba de aceptación). Cada nivel tiene objetivos, alcance y responsabilidades definidos.
Un nivel de prueba es un conjunto organizado de actividades con objetivos específicos, aplicado a un objeto de prueba particular. En “component testing” se valida una unidad aislada (p. ej., un módulo o clase); en “integration testing” se evalúan interfaces e interacciones entre componentes/sistemas; en “system testing” se verifica el comportamiento end-to-end del sistema completo frente a requisitos; y en “acceptance testing” se confirma la idoneidad para uso y los criterios de aceptación con el cliente/usuario. Esta estratificación ordena el riesgo, facilita la trazabilidad y evita solapamientos u “huecos” de cobertura entre equipos y entregables.
Aplicabilidad
1App de pagos:
- Componente: cálculo de comisiones de tarjeta.
- Integración: API de pagos ↔ gateway ↔ conciliación bancaria.
- Sistema: flujo completo de compra y reversa.
- Aceptación: usuario de negocio valida reglas impositivas y reportes.
2) Distinguir los diferentes tipos de prueba (K2)
Tres familias conceptuales: “functional testing” (pruebas funcionales), “non-functional testing” (pruebas no funcionales, p. ej., “performance”, “usability”, “security”) y “change-related testing” (pruebas relacionadas con cambios), que incluyen “confirmation” (confirmación) y “regression” (regresión).
Un tipo de prueba clasifica el objetivo de calidad a evaluar. Las pruebas funcionales verifican qué hace el software según requisitos y reglas de negocio. Las no funcionales evalúan cómo lo hace (rendimiento, capacidad, seguridad, usabilidad, compatibilidad, fiabilidad, etc.), aportando señales de calidad operativa. Las relacionadas con cambios controlan el riesgo de modificación: tras corregir o ajustar código/configuración, se confirma el arreglo y se verifica que no haya efectos colaterales. Distinguir nivel (dónde/cuándo) de tipo (qué objetivo de calidad) permite planificar matrices de cobertura coherentes y alinear evidencias con los criterios de aceptación.
Aplicabilidad
Misma historia “pago con tarjeta”:
- Funcional: autoriza con regla de límite y moneda.
- No funcional (performance): latencia p95 < 300 ms en pico.
- Seguridad: OWASP para inyección/CSRF.
- Cambio: tras refactor, confirmar el fix y ejecutar regresión crítica.
3) Distinguir la prueba de confirmación de la prueba de regresión (K2)
“Confirmation testing” (prueba de confirmación) re-ejecuta pruebas que antes fallaron para demostrar que el defecto fue corregido. “Regression testing” (prueba de regresión) explora impacto colateral: verifica que otros comportamientos no se hayan roto por el cambio.
Aunque ambas se desencadenan por un cambio, sus fines difieren. La confirmación (a veces “retest”) toma el mismo caso que evidenció el defecto (y sus datos), ahora debería pasar con el fix aplicado: valida la eficacia de la corrección. La regresión ejecuta un conjunto seleccionado (priorizado por riesgo) sobre áreas susceptibles de verse afectadas por el cambio, aunque no hayan fallado antes: busca defectos introducidos o reaparecidos. Una práctica madura separa ambas ejecuciones, traza la relación cambio→pruebas y automatiza la regresión para obtener feedback rápido.
Aplicabilidad
Se corrige un cálculo de comisiones.
- Confirmación: re-ejecutar el caso “comisión=0.50%” que falló.
- Regresión: suite de tarifas y monedas, reversa de pago y reportes para detectar efectos colaterales.
Dependencias entre los objetivos
- Niveles ↔ Tipos: Todo tipo de prueba puede (y debe) planificarse en uno o más niveles. Ej.: “security testing” (tipo no funcional) a nivel sistema y también a nivel integración (p. ej., hardening de APIs).
- Cambio-relacionadas ↔ Niveles: “Confirmation” y “regression” (tipos de pruebas relacionadas con cambios) se ejecutan en el nivel donde el riesgo es más alto: a veces basta con componente; otras, requiere integración y sistema.
- Planificación: Distinguir correctamente “nivel” (estructura/objeto) y “tipo” (objetivo de calidad) permite construir matrices de cobertura claras y evitar duplicidades o brechas, optimizando el riesgo de producto y el riesgo de proyecto.
