Los conceptos costes de calidad y costes de no calidad son de aparición reciente en el sector del desarrollo software si lo comparamos con las muchas décadas que estos conceptos se utilizan en otros sectores como la ingeniería industrial o la construcción.
En sectores veteranos, el análisis económico de la calidad se realiza en base a los siguientes conceptos:
- Costes de detección: Costes de busqueda del defecto en el producto.
- Costes (inversión) en prevención: Costes para evitar que el proceso inyecte defectos en el producto.
- Costes de fallo interno: Son los costes de reparación de los defectos encontrados antes de entregar el producto. Tambien hay que contabilizar los costes de mejora del proceso para evitar la repetición de ese fallo.
- Costes de fallo externo: Son los costes originados por el fallo una vez entregado el producto. Aquí no sólo hay contabilizar los costes de reparación o correción del defecto, sino la potencial pérdida de confianza, o incluso, penalizaciones derivadas del fallo.
Aplicando estos conceptos al sector del desarrollo software este análisis quedaría:
- Costes de las pruebas: Costes derivados de probar el software para evitar que los defectos lleguen a producción.
- Prevención: Costes derivados de mejorar los procesos de desarrollo (herramientas, técnicas, arquitectura, métodos, prácticas) y de capacitación de las personas (formación) para minimizar la inyección de defectos en el software.
- Costes del fallo interno (retrabajo): Costes de búsqueda y corrección del defecto así como repetición de las pruebas derivados de haber encontrado un defecto antes de liberar el software. No sólo hay que tener en cuenta el coste de repetir la prueba que originó el fallo (retest) sino la posible regresión de pruebas y los costes asociados a un nuevo paso a producción que suelen ser los mayor cuantía.
- Costes del fallo en producción: En este escenario no sólo hay que sumar los costes equivalentes al fallo interno, sino el daño producido al cliente, usuario o el propio negocio donde se utiliza el software. La pérdida de confianza y las posibles penalizaciones o sanciones suelen ser los mayores costes de este tipo de fallos.
Los costes de los fallos, tanto internos como externos, son especialmente altos en el software que tiene una deuda técnica alta provocada por una baja mantenibilidad, baja fiabilidad y una inadecuada arquitectura de componentes. Una deuda técnica alta suele elevar los costes de:
- reproducción del fallo
- localización del defecto
- corrección del defectos
- evitar fallos colaterales al aplicar la corrección
- repetición de las pruebas (regresión)
- aplicación de medidas preventivas para evitar la repetición del defecto.
La primera referencia clara que dispongo de esta visión de los costes de calidad y no calidad en el software lo encontré durante la preparación de la certificación CSQE (Certified – Software Quality Engineer) de la ASQ (American Society for Quality). La segunda referencia la encontré en el curso de formación como Test Manager de ISTQB® (International Software Testing Qualifications Board) del syllabus de 2012 donde mapeaba los costes de calidad y fallo con los homólogos de los procesos industriales de décadas anteriores.
Actualmente podemos encontrar cientos de referencias buscando por «coste de calidad / costes de no calidad» (quality costs / non quality costs).
Los gráficos asociados a estos conceptos son similares a los mostrados a continuación, donde los costes de calidad representan los costes de detección y prevención y los costes de no calidad los costes del fallo interno y externo.
En abcisas se muestra el grado de calidad (costes de prueba y prevención) aplicado al proceso de desarrollo software.
Lo más llamativo es la curva exponencial que siguen los costes de las pruebas conforme intentamos conseguir un alto grado de calidad (probarlo todo). Estó está causado por el efecto exponencial del coste de las pruebas que se demuestra estudiando los fundamentos de las pruebas software (ver Syllabus del ISTQB Foundation Level). Uno de sus principios dice que probar un software complejo de forma exhaustiva es prácticamente imposible o, al menos, inviable económicamente.
La curva de los costes de no calidad tienen una distribución simétrica a los costes de calidad. Su interpretación es que no probar nada (nivel de calidad del 0%) tiene costes muy altos ya que posiblemente el software nunca llegue a utilizarse o, si se utiliza, puede causar daños graves al negocio.
Aplicando estratégias de prueba adecuada, y con unos costes de calidad muy contenidos, podemos reducir los costes de no calidad al demostrar con las pruebas que los fallos más dañinos para el negocio no se dan en el software o, si se dan, los corregiremos antes del paso a producción. Conforme vamos aumentando el nivel de calidad los costes de las pruebas van aumentando de forma exponencial y los costes de la no calidad van estabilizandose ya que cada vez las pruebas son más complejas y costosas y abordan fallos menos dañinos.
Pero llegamos a un punto en que el coste de las pruebas es superior al daño que tratamos de evitar. En este punto la economía de las pruebas nos dice que no es rentable ampliar la cobertura de las pruebas, ya que buscar los fallos nos costaría más que el efecto de que el software falle en producción. Suele resultar sorprendente para un tester el mensaje de «es recomendable no probar más».
Obviamente, la gráfica representa un concepto y la base de una estrategia de calidad económicante rentable. La distribución del coste de las pruebas y el coste del fallo propio de cada prueba no sigue una distribución que coincide exactamente con el gráfico.
El gráfico trata de trasmitir, de una manera sencilla, los siguientes conceptos:
- No realizar pruebas o no realizar las pruebas adecuadas supone un coste de no calidad (fallos, retrabajo, despercio) muy alto
- Intentar probarlo todo puede suponer un coste varias veces superior al coste del desarollo del software.
La correcta elección de la estrategía de las pruebas produce un coste total mínimo
Del gráfico anterior no debemos concluir que el punto central (50%) siempre será el punto óptimo o de coste mínimo. Veamos algunas situaciones donde el punto óptimo se situa en otros lugares y el motivo por el que dicho punto se desplaza.
El siguiente gráfico responde a un software crítico (aeroespacial, safety). El coste del fallo es extremadamente alto y provoca el desplazamiento hacia la derecha evidenciando que es económicamente más rentable probar más.
El siguiente gráfico responde a un software de baja criticidad donde el coste de la no calidad es muy bajo provocando un desplazamiento a la izquierda evidenciando que en más rentable probar menos
En el siguiente gráfico vemos que a igualdad de costes de no calidad y mejorando la eficiencia del proceso de desarrollo (estrategias de desarrollo que provocan pruebas más baratas) el gráfico se desplaza a la derecha, provocando que con un menor coste total de calidad, se consiga mejor cobertura de las pruebas y mayor nivel de calidad del software. Software mejor y más barato
Como ya se ha mencionado, estos modelos de distribución de costes son teóricos y no se ajustan a la perfección con los costes reales de un producto software. Pero trasmiten un mensaje claro sobre donde debemos poner el foco para desarrollar software de mejor calidad y más barato: una adecuada arquitectura software, una correcta estrategia de pruebas y un eficiente proceso de desarrollo.
Aurelio Gandarillas