Pruebas a lo largo del Ciclo de Vida
Explica cómo el modelo de desarrollo influye en las pruebas. Incluye buenas prácticas aplicables a cualquier SDLC, enfoques test-first, DevOps, shift-left, retrospectivas, niveles de prueba, tipos de prueba, confirmación, regresión y mantenimiento.
Pruebas dentro del SDLC
El modelo de desarrollo condiciona cuándo, cómo y con qué frecuencia se prueban los productos. En modelos iterativos y ágiles se espera retroalimentación continua; en secuenciales es clave introducir revisión y diseño de pruebas temprano.
- Siempre debe existir una actividad de prueba relacionada con las actividades de desarrollo.
- El diseño de pruebas temprano ayuda a encontrar defectos en requisitos o historias.
- La selección de niveles, tipos y documentación depende del contexto.
Test-first, DevOps y shift-left
El syllabus v4.0 incorpora prácticas modernas: TDD, ATDD, BDD, DevOps y shift-left. Todas buscan retroalimentación más rápida y calidad incorporada al flujo de desarrollo.
- TDD se centra en pruebas que guían el diseño del código.
- ATDD y BDD conectan criterios de aceptación con ejemplos y comportamiento esperado.
- DevOps integra pruebas, integración continua, entrega continua y monitoreo.
- Shift-left mueve actividades de prueba hacia momentos más tempranos.
Niveles, tipos y cambios
Nivel de prueba y tipo de prueba no son lo mismo. Los niveles organizan alcance; los tipos expresan el objetivo de la prueba.
- Niveles: componente, integración, sistema y aceptación.
- Tipos: funcionales, no funcionales, caja blanca y relacionados con cambios.
- Confirmación verifica una corrección; regresión busca efectos colaterales.
- Mantenimiento se activa por cambios, migraciones, actualizaciones, correcciones o retiro del sistema.
Términos clave
Objetivos de aprendizaje
- FL-2.1.1 · K2Explicar impacto del SDLC elegido en las pruebas
El SDLC define el momento y forma de las pruebas. En secuencial, el riesgo es detectar tarde; en iterativo/ágil, se prueba de forma continua e incremental.
- FL-2.1.2 · K1Recordar buenas prácticas de prueba aplicables a todos los SDLC
Buenas prácticas: cada actividad de desarrollo tiene actividad de prueba asociada, los testers participan temprano, se definen niveles apropiados y se aplica revisión sobre productos de trabajo.
- FL-2.1.3 · K1Recordar ejemplos de enfoques test-first
Test-first incluye TDD, ATDD y BDD. Se definen pruebas, ejemplos o criterios antes o durante el desarrollo para guiar construcción.
- FL-2.1.4 · K2Resumir impacto de DevOps en pruebas
DevOps integra desarrollo, pruebas y operaciones mediante automatización, CI/CD, monitoreo y retroalimentación rápida.
- FL-2.1.5 · K2Explicar shift-left
Shift-left mueve actividades de calidad hacia etapas tempranas: revisión, análisis de pruebas, criterios de aceptación, estáticas y automatización temprana.
- FL-2.1.6 · K2Explicar retrospectivas como mejora de procesos
Las retrospectivas identifican mejoras de proceso basadas en experiencia real. Deben producir acciones concretas y seguimiento.
- FL-2.2.1 · K2Distinguir niveles de prueba
Los niveles de prueba agrupan objetivos y responsabilidades por alcance: componente, integración, sistema y aceptación.
- FL-2.2.2 · K2Distinguir tipos de prueba
Tipos de prueba se enfocan en objetivos: funcional, no funcional, caja blanca y relacionado con cambios.
- FL-2.2.3 · K2Distinguir prueba de confirmación y regresión
Confirmación verifica si un defecto corregido ya no ocurre. Regresión verifica que los cambios no dañaron funcionalidades existentes.
- FL-2.3.1 · K2Resumir pruebas de mantenimiento y activadores
Las pruebas de mantenimiento se realizan cuando cambia el sistema, su entorno, datos, configuración, plataforma o cuando se migra o retira.
Errores frecuentes
- Nivel de prueba no es lo mismo que tipo de prueba.
- Confirmación verifica si la corrección resolvió el defecto; regresión verifica efectos colaterales.
- Shift-left no significa eliminar pruebas tardías; significa probar antes y mejor.
- DevOps no elimina la necesidad de pruebas; las integra en el flujo.
Ejemplos aplicados
- En una API de pagos, pruebas de componente validan funciones pequeñas; integración valida comunicación con host; sistema valida el flujo completo; aceptación valida necesidad de negocio.
- Después de corregir un reverso, haces confirmación sobre el reverso corregido y regresión sobre compras, anulaciones y cierres afectados.