Primero, es importante tener claro que para la gestión de cualquier tipo de proyecto o iniciativa, siempre debemos incluir la actividad de identificar los posibles eventos o situaciones que de convertirse en realidad pueden afectar los objetivos, los recursos, las personas y las expectativas que esperamos lograr al finalizar ese proyecto o iniciativa.
Es la respuesta a la pregunta: ¿Qué puede impedir que logremos los objetivos que nos hemos trazado? ¿Qué situaciones pueden hacerse realidad que no nos permitan progresar de acuerdo con lo planeado? Esos eventos que pueden suceder se conocen como RIESGOS DE PROYECTO. Y deberían ser identificados por todo el equipo completo, lo más temprano posible en el proyecto, con el fin de definir el plan de acción para mitigarlo, transferirlo o controlarlo.
Sin embargo, también existen otro tipo de riesgos que de materializarse, van a impedir que entreguemos el producto de software esperado con el nivel de calidad deseado. ¿La pregunta es cuál de las características que determinan el nivel de calidad puede fallar, en un futuro, cuando el producto de software se encuentre operando en producción con usuarios reales y con datos reales? Para eso siempre sugiero analizar el producto a la luz del estándar ISO/IEC 25010, como una guía para identificar dónde pueden estar las más importantes vulnerabilidades del software.
ISO/IEC 25010, estándar que nos propone un modelo de referencia de cuáles son las características claves o principales que debe tener un producto de software para lograr la calidad.
Cuando analizamos el producto de software desde los posibles riesgos de la calidad (RIESGOS DE PRODUCTO), nuestra perspectiva es enriquecida con nueva información que nos permite tener un mejor entendimiento del negocio (necesidades y expectativas) y de los aspectos técnicos del mismo (componentes de arquitecturade diseño entre algunos).
Pero claro que requiere un trabajo colaborativo de todo el equipo, pero la recompensa es una visión compartida y una mejor comunicación.
Entonces, en este punto yo misma me cuestiono sobre el título de este post. No es sobre las pruebas basadas en los riesgos de producto. Es sobre un equipo de trabajo que durante la ideación e implementación de una iniciativa, considera los RIESGOS DE PRODUCTO y DE PROYECTO como una herramienta para conocer mejor la posible solución e identificar dónde debemos ser más cuidadosos, no solo en las pruebas sino en la especificación de la necesidad, en el diseño de la solución y en la codificación.
Entonces, cambiaría el titulo de. “¿Qué es eso de las Pruebas basadas en Riesgos?” por “¿Qué es eso de iniciativas basadas en el Riesgo?”
¿Cómo lo hace hoy tu equipo?
Testing Knowledge 