Blog

Definición y Alcance

Este principio afirma que no es posible probar todas las combinaciones posibles de entradas, salidas y condiciones en un sistema, excepto en casos muy simples y triviales. En proyectos de software reales, la cantidad de posibles combinaciones de datos, flujos de ejecución y estados del sistema es prácticamente infinita, lo que hace imposible ejecutar todas las pruebas posibles.

Explicación

El objetivo de las pruebas no es cubrir absolutamente todas las posibles ejecuciones del sistema, sino identificar las áreas más críticas y donde los defectos son más probables. Por esta razón, se deben utilizar técnicas de selección y priorización de pruebas. El enfoque más común para manejar este desafío es utilizar técnicas de prueba sistemáticas, como las pruebas basadas en riesgo, donde se enfocan los esfuerzos en las áreas más vulnerables o más propensas a fallar.

Las técnicas como la partición de equivalencias o el análisis de valores límite ayudan a reducir el número de casos de prueba al agrupar escenarios similares que pueden ser representados por un solo caso de prueba. Además, el uso de pruebas basadas en el riesgo permite al equipo identificar las áreas de mayor impacto y priorizarlas, maximizando así el valor de las pruebas ejecutadas.

Ejemplo

Imaginemos que estemos probando la funcionalidad de «Buscar paquete» en la aplicación web de venta de paquetes de viajes. Para probar todas las posibles combinaciones de destinos, fechas y lugares de origen, necesitaríamos varios conjuntos de pruebas solo para cubrir todas las combinaciones posibles de entradas. En lugar de tratar de probar cada combinación, podemos usar partición de equivalencias para seleccionar un subconjunto representativo de los datos de entrada. Por ejemplo, podríamos agrupar todos los destinos europeos en un solo caso de prueba y todos los destinos de América del Sur en otro. Además, el análisis de valores límite nos ayudaría a probar solo los extremos del rango de fechas válidas en lugar de todas las posibles fechas intermedias.

Momento para reflexionar:

En entornos ágiles, donde los plazos son cortos y los ciclos de desarrollo son rápidos, este principio es fundamental. Debemos concentrarnos en probar los aspectos más relevantes del sistema y no intentar abarcarlo todo. Las pruebas automatizadas tanto de front como de back end también juegan un papel importante aquí, ya que permiten ejecutar múltiples escenarios en paralelo sin intervención manual, pero incluso con automatización, nunca se alcanzará una cobertura total del sistema. Aquí vuelvo a reiterar la importancia que tienen las historias de usuario y sus correspondientes criterios de aceptación bien alcanzadas, para luego conversar con el Product Owner e intercambiar ideas para mejorar todo lo que se pueda el alcance de nuestras pruebas.