¿Controla el ROI de las pruebas de software?

¿Tiene su organización los indicadores necesarios para controlar el ROI de los servicios de pruebas de software?

Habitualmente la respuesta a esta pregunta suele ser no. Y no porque no se desee, sino porque no se dispone de elementos para justificar el beneficio tangible (económico) que aportan las pruebas y la gestión de la calidad.

Si no puede, está en la misma situación que la mayor parte de las compañías que invierten grandes cantidades de dinero en mejorar la calidad de sus aplicaciones, pero sin conseguir convertir esa mejora de la calidad en un ahorro de dinero. Según el World Quality Report 2013-2014:

• El 73% de las empresas tan sólo obtienen estadísticas del número de defectos encontrados en los desarrollos y un 45% declara que detectan demasiado tarde los errores, lo que multiplica los costes para subsanarlos y retrasa la puesta en producción.
• Además, muchas compañías aún no son capaces de demostrar qué valor aporta al negocio asegurar la calidad.

Estos problemas se agravan cuando se trata de servicios externalizados, de probar sistemas móviles, aplicaciones SOA o desarrollos sobre paquetes como SAP, SIEBEL.

Esto ocurre porque los equipos de Pruebas se encargan de la parte más técnica de las pruebas, pero no se suele tener en cuenta que el resultado de estas actividades técnicas se debe usar para facilitar a la dirección de IT la toma de decisiones.

Tradicionalmente se entiende por Gestión de las Pruebas el conocer en qué punto del proyecto estamos: cuántos casos de pruebas se han ejecutado, cuántos casos de prueba han fallado, cuántos defectos se han detectado, de qué tipo, en qué componentes, con qué grados de criticidad, cuántos se han corregido, cuántos quedan por corregir, …

Es importante saber dónde estamos, pero mucho más importante para poder tomar decisiones adecuadas es saber cuánto nos queda para llegar a dónde queremos ir, que hay que hacer para llegar a esa situación. Y si además esta información se presente con la suficiente antelación, de tal forma que haya suficiente margen de reacción, mucho mejor.

Para que esto no ocurra y nos quedemos únicamente en el aspecto más técnico, es necesario complementar los equipos de pruebas independientes que se encargan de realizar y gestionar (conseguir que las pruebas estén organizadas) con una función que se encargue de gobernar las pruebas y que facilite la toma de decisiones poniendo blanco sobre negro las implicaciones que las decisiones tienen en términos de riesgo asociado a la mejora o pérdida de calidad.

Esa función de gobierno de pruebas la aporta una Oficina de Gobierno de Pruebas o TMO (Testing Management Office) que, a semejanza de lo que ocurre en desarrollo, se focalice en los aspectos más relacionados con la gestión y no solo con a parte técnica.

Se entiende por gobernar las pruebas el realizar un conjunto de actividades que complementan y que dan valor a las actividades realizadas por los equipos de pruebas, además de optimizar la forma de trabajo aumentando la productividad y eficiencia de los equipos de trabajo.

Este conjunto de actividades tienen como punto de partida el implantar un modelo de estimaciones de pruebas, que no esté basado en un porcentaje de un supuesto esfuerzo de desarrollo, y que tengan una precisión suficiente, de tal forma que puedan ser usadas durante el desarrollo y pruebas del proyecto para anticipar la situación que se producirá una vez entregado el software a Negocio para su aceptación y su posterior puesta en producción.

La forma más adecuada de realizar estas estimaciones de pruebas o testware (entendiendo como tal el conjunto de elementos más relevantes que componen unas pruebas como son los planes de prueba, los casos de prueba, los defectos y las incidencias en producción) es basarlas en una métrica internacional como son los puntos función para calcular los volúmenes de testware requeridos para cada una de las etapas del proyecto y aplicando unas productividades de pruebas convertirlas en los esfuerzos requeridos.

Estas estimaciones del testware del proyecto será el elemento conductor de las acciones de seguimiento y gobierno de pruebas que permitirá complementar la información de dónde estamos, con la información de cuánto nos queda para llegar a dónde debemos estar y hacerlo de forma anticipada.

En definitiva nos permite contestar a un buen número de preguntas importante que la dirección de IT se hace, o se debería hacer, sin usar la palabra “depende” que no aporta ningún elemento de seguridad a la hora de tomar decisiones importantes: