Ignacio López Carrillo

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, …

La importancia de saber dónde estamos

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.