Jhon Alexander Betancur Buitrago 25 julio, 2022Identificar riesgos de fallo en nuestro software y determinar posibles soluciones no es una tarea sencilla. Requiere de un verdadero análisis para que podamos finalizar con un buen plan de contingencia que mejore la calidad de nuestro software.
Aunque siempre se establece que en las pruebas de software hay una serie de fases necesarias para determinar su viabilidad, y posteriormente ser aprobado, es importante reconocer que se puede prevenir fallos si se identifica los riesgos de producto o los riesgos de proyecto.
¿Qué es el riesgo de producto o de proyecto?
En primer lugar, un riesgo de proyecto es una afectación en la administración y control de un proyecto de software que se prueba lo cual se puede medir y detectar para que haya un mejor éxito en la implementación de dicho sistema de información; poder entregarlo con la mejor calidad posible y en las condiciones necesarias para que el cliente quede satisfecho.
Un ejemplo muy común de riesgo de proyecto, son los requerimientos poco definidos que tienden a variar en detalles que pueden crear un vacío en la comunicación entre todo el engranaje que acompaña el diseño, desarrollo y pruebas, y que desencadena un tiempo mayor en la implementación, por ende en la aceptación del cliente. Por eso es importante también documentar el software, para que tanto los requerimientos como las pruebas, queden como información que se va a poder consultar posteriormente, para realizar un plan de pruebas basado en riesgos, cada vez más sólido.
También, se pueden identificar muchos otros riesgos como por ejemplo riesgo de producto, que son eventualidades que afectan la calidad del producto cuyo resultado puede ser bastante negativo para la percepción que tienen los clientes del sistema de información y se puede identificar mediante un análisis de riesgos con los stakeholders.
De la misma manera, un testing basado en riesgos evitaría una pérdida de confianza en el producto, pérdida de clientes y pérdida de recursos económicos. Por eso hacer este tipo de testing es imperativo.
¿Cómo puedo hacer testing basado en riesgos?
Lo primero que debemos establecer es identificar los riesgos con técnicas como por ejemplo usando listas de comprobación, entrevistando a los expertos, retrospectivas del proyecto etc. Luego procedemos a categorizar los riesgos (funcionalidad, rendimiento, fiabilidad) y bajo una matriz de riesgos analizamos el nivel de eventos críticos cuya probabilidad versus Impacto puede ser bajo, medio o alto.
Finalmente, se puede concluir que existen muchos factores que pueden afectar la probabilidad del riesgo tales como: la falta de testing en fases tempranas, demasiados cambios, complejidad del proyecto etc. En fin, un testing basado en riesgos nos ayuda a visibilizar la cobertura de lo que se quiere probar y su alcance, como también decidir con mucha anticipación cómo mitigar esos riesgos. Con esta técnica también se puede prevenir la ya conocida “Paradoja del pesticida”.
¿Cómo harías tus pruebas basadas en riesgos y qué otras técnicas conoces que puedan ayudar a prevenir defectos? Déjanos en los comentarios tus opiniones acerca de este tema.
