¿Mucho para probar y con tiempo limitado? Te explicamos cómo crear una matriz de riesgo de pruebas de software para obtener los mejores resultados.

Cuando se trata de probar software, puede ser un poco abrumador al incio. Un recurso al que se puede recurrir es la software testing wheel que creamos en Abstracta, basada en los estándares ISO 25010 para la calidad del producto de software. Esta wheel explica todos los diferentes factores de calidad y cómo probarlos. Pero, pronto tendrás claridad de las cosas que deben probarse solo con el tiempo y los recursos limitados con los que cuentas.

Ahí es cuando tienes que aplicar el principio de pareto : ¿Cuál es ese 20% de cosas que puedes probar que crearán el 80% del valor de la prueba? O para decirlo de otra manera, adopta un enfoque Risk-Based Testing, eligiendo tareas que te permitan mitigar primero los aspectos con mayor riesgo. En este post te mostraré una actividad que propone hacer este análisis usando una matriz de riesgo para las pruebas de software.

Matriz de Riesgo

El riesgo se compone de dos factores: la probabilidad de que algo suceda y el impacto comercial (negativo) que tendría. Entonces, si lo ilustramos en una matriz, podremos distinguir zonas según el riesgo, donde los extremos serán:

1. Muy probable, alto impacto: ¡Debemos probarlo!
2. Improbable, alto impacto : Deberíamos probarlo.
3. Muy probable, bajo impacto : si hay tiempo, podríamos probarlo.
4. Improbable, bajo impacto : si queremos tirar el dinero por el desagüe, probaremos esto. Es decir, la prueba es demasiado cara para el valor que proporciona. Entonces, no lo probaremos.

Esto está asociado con el método MoSCoW: M for Must Have (Debe tener), S de Should Have (Debería tener), C de Could have (Podría tener) y W de Won’t have but would like to in the future (No tendrá pero me gustaría en el futuro)

La siguiente imagen muestra una matriz para realizar un análisis de riesgo con este método (y no, no está en el mismo orden que la matriz anterior):

También puedes optar por una versión más refinada de la matriz :

Cómo hacer tu propia matriz de riesgo de prueba de software

Estos son los pasos para hacer su propia matriz de Risk-Based Testing para diseñar un plan de prueba sólido:

1. Piensa en los factores que afectan la probabilidad de que aparezca un incidente o error

Por ejemplo, la complejidad de la solución o la dependencia de sistemas externos-

2. Piensa en los factores que generan un impacto negativo en el negocio, en caso de que la funcionalidad tenga problemas

Por ejemplo, funcionalidades que operan con datos sensibles y características más utilizadas.

3. Luego, implementa este método de diferentes maneras, pensando en las técnicas de prueba a aplicar o las funcionalidades a probar, etc.

Por ejemplo, puedes colocar las diferentes funcionalidades o poner “tests de seguridad”, “tests de perfirmance”, etc., en los diferentes cuadrantes. También podría aplicarse para decidir qué características necesitarán qué tipos de pruebas. Otro ejemplo es usarlo para definir cuánto tiempo debe dedicar a las pruebas exploratorias para cada funcionalidad.

A continuación te mostramos un ejemplo de cómo nos gusta armar nuestra matriz en Abstracta, en la que los cuadrantes son según el riesgo, e incorporamos la técnica MoSCoW:

Algo que nos ha parecido interesante, es que a partir de esta matriz de riesgo, se podría separar la Defnition of Done (DoD), distinguiendo diferentes DoDs según la criticidad de la historia/funcionalidad del usuario.

Luego, para algunas historias etiquetadas como categoría 3 (las “Podrían”), se pueden definir ciertos tipos de pruebas, automatización con cuánta cobertura, etc. Después, para otro ítem categorizado como 1 (“Debe”) habrá una diferente DoD, con otras tareas asociadas que son más exigentes en términos de control de calidad.

Esta técnica también puede ser muy útil para una retrospectiva, centrándose en tareas de calidad.

¿Has utilizado antes el enfoque Risk-Based Testing o una matriz de trazabilidad de requisitos similar, pero diferente? ¡Cuéntanos tu experiencia en los comentarios!

¡Síguenos en LinkedIn, Twitter, Facebook, Instagram y YouTube para ser parte de nuestra comunidad y enterarte de más novedades respecto a las pruebas!

Otros contenidos relacionados

Beneficios de Shift Left Testing en el Ciclo de Desarrollo de Software

Cómo crear la estrategia de pruebas adecuada para tu proyecto

5 Beneficios de adoptar Agile en Proyectos de Desarrollo de Software