Blog

Definición y Alcance

Este principio establece que identificar y corregir defectos en las primeras etapas del desarrollo del software es más eficiente en términos de tiempo y dinero. Los errores descubiertos al principio del ciclo de vida del desarrollo tienen menos impacto en el proyecto en comparación con aquellos encontrados más tarde. Detectar defectos en las fases tempranas evita que estos defectos se propaguen y generen fallos en fases posteriores, lo que reduciría los costos de corrección y el tiempo necesario para solucionarlos.

Explicación

Cuando los defectos los identificamos tarde, es probable que hayan afectado múltiples componentes del sistema, lo que complica y encarece su corrección. Además, los errores que se encuentran en las etapas finales del proyecto pueden provocar retrasos significativos, ya que, en muchos casos, requieren reescribir o modificar partes sustanciales del software, y por supuesto volver a realizar nuestro testing con todo lo que eso conlleva, sólo para citar algunas actividades: administración de datos a usar para las pruebas, identificación de casos de prueba que deban incluirse en pruebas de regresión y de integración, corroboración del alcance de las pruebas de confirmación, adecuación si correspondiera de los casos de prueba a ejecutar.

Ejemplo

Imagina que estamos trabajando en una aplicación web para vender paquetes turísticos. Si en la fase de diseño de la funcionalidad «Buscar paquete» se realiza una revisión estática de los requisitos, podríamos identificar inconsistencias o ambigüedades en cómo deben funcionar los filtros de búsqueda. Corregir estos problemas en esa fase implica solo ajustar la documentación o tener una breve reunión con el equipo. Sin embargo, si estos problemas se detectan cuando la funcionalidad ya está implementada, corregirlos puede implicar cambios significativos en el código, lo que afectará el calendario del proyecto y aumentará los costos.

Momento para reflexionar:

En este sentido, la aplicación del principio de «shift-left» o desplazamiento hacia la izquierda es clave. Este enfoque implica que las actividades de prueba comiencen lo antes posible en el ciclo de desarrollo, incluso durante la fase de análisis y diseño, no esperando a que el código esté completamente desarrollado. Tanto las pruebas estáticas (como revisiones y análisis de código) como las pruebas dinámicas se benefician de este enfoque, ya que pueden iniciarse en paralelo con el desarrollo, permitiendo la detección temprana de defectos. Aquí sigo insistiendo en la importancia de tener una historia bien alcanzada tanto a nivel funcional como no funcional para que podamos no sólo comprender su alcance sino además, elaborar nuestros artefactos de trabajo correctamente. Por supuesto, y también como siempre te lo volveré a repetir, es importante que tengas las charlas que sean necesarias con los desarrolladores y/o con el Product Owner cuando corresponda para ponerse de acuerdo en el alcance y que realmente comprendamos la necesidad del negocio para generar el producto esperado y así tener éxito en la Review.