¿Qué es una estrategia de RBT ?

El deseo de implantar en producción el software de forma rápida y con recursos limitados crea la necesidad de establecer algún criterio de actuación cuando los tiempos y recursos no son suficientes. El testing , como tal, tiene el objetivo de reducir al mínimo la probabilidad de que un producto defectuoso llegue a los usuarios finales.

Muchas veces el tiempo y la cantidad de recursos disponibles para las pruebas de un producto son mucho menores que las estimaciones de planificación y esfuerzo correspondientes. Algunas veces puede deberse a que el equipo de desarrollo entregue la versión final del software fuera de plazo y el equipo de testing no consiga replanificar el calendario de pruebas. Otras veces es la escasez en el número de testers  con el conocimiento funcional  y habilidades técnicas deseadas para cumplir con la planificación. Con independencia de las causas de la demora, el Test Manager a menudo se enfrenta a la tarea de decidir qué probar antes de que el equipo se quede sin el tiempo o el dinero asignado para la prueba. Cuando nos enfrentamos a situaciones como éstas, un Test Manager a menudo tiene que tomar decisiones desagradables. Puede haber una serie de factores en los que se pueden basar estas decisiones. Sin embargo, una de las mejores maneras de manejar esta situación es realizar RBT (Risk-based testing).

¿Qué son las Pruebas basadas en el riesgo (RBT)?… si  entendemos que un riesgo es un evento con un resultado potencialmente negativo que pueden ocurrir en cualquier momento en el futuro, la ocurrencia (o no ocurrencia) de un riesgo no puede garantizarse de antemano. Cuando se prueba un producto con un número limitado de testers en una pequeña cantidad de tiempo, tenemos que reducir la cantidad de pruebas que se pueden realizar.

Aquí es donde el concepto de RBT entra en juego: las pruebas basadas en el riesgo implican la comprensión de los riesgos asociados al lanzamiento de un producto sin realizar  pruebas exhaustivas en él. Puede haber algunas de las características de una aplicación que son más susceptibles de ser utilizados por los usuarios finales en comparación con otras características que se pueden usar en raras ocasiones. Por ejemplo, en una aplicación de banca el modulo de apertura de cuentas es probable que se utilice con mucha más frecuencia en comparación con otros módulos. Esta información se utiliza en RBT con el fin de dar prioridad a la planificación de las pruebas y determinar qué se puede probar dentro de la limitada cantidad de tiempo / recursos disponibles para las pruebas.

Las premisas básicas para aplicar el RBT son:

1. Identificar posibles riesgos que pueden ocurrir si los módulos / funciones de una aplicación no se prueban a fondo (o completamente).

2. Determinar el probable impacto de cada riesgo, así como la probabilidad de su ocurrencia. ¿Qué ocurrirá si se produce el riesgo? ¿En cuánta pérdida monetaria (o de otro tipo) se incurrirá, y cuál es la probabilidad de que ocurra? Asignar  valores entre 0 y 1 para la probabilidad relativa de ocurrencia y de 0 a 3 para el impacto probable de cada riesgo identificado. Asignar valores superiores a los riesgos con mayor probabilidad de ocurrencia e impactos probablemente más altos, y los valores comparativamente inferiores a los demás.

3. Multiplicar los valores de probabilidad relativa de ocurrencia y posible impacto para cada riesgo identificado, con el fin de llegar a un valor numérico único para cada uno de ellos.

4. Afrontar  las actividades de pruebas que eliminen los riesgos con los más altos valores numéricos (según lo calculado en el paso 3) en primer lugar. Actividades de prueba posteriores deben ser dirigidas a la prevención de los riesgos con los siguientes valores numéricos en forma decreciente.

La conclusión de todo esto es que siguiendo este enfoque, un Test Manager puede garantizar que se realicen pruebas más eficaces con recursos y tiempo limitados.

Más información:

Jose Luis Pérez Pan 

Ingeniero de Test Senior 

jose-luis.perez-pan@sogeti.com