Los costes de la calidad y la no calidad

En países como Holanda está muy arraigada la cultura del testing de software y lo que es más, del aseguramiento de la calidad. Sin embargo en España se hace testing de software desde hace relativamente poco tiempo y aún sigue sin ser una prioridad para las empresas.

Son muchas las que no comprenden completamente la importancia del testing, no consideran que un tester deba tener unas habilidades o conocimientos específicos o que sea necesaria una planificación, una estrategia de pruebas, un análisis de riesgos del proyecto y del producto o una actividad más allá de la ejecución de casos de prueba. El testing para muchos es una fase del proyecto tras el desarrollo que retrasa el despliegue del software en producción… y lo que es peor y más en estos tiempo… el testing es caro, ¡muy caro! ¿Es esto verdad?

Veamos. Los gastos de la calidad se pueden dividir en 2 grandes bloques:

  • Prevención de defectos
  • Detección de defectos

Cuanto mejor se prevengan y detecten defectos menor será el coste de la NO calidad. Los costes de la calidad se miden con relativa facilidad, pero los de la no calidad no son tan objetivos. ¿Cuánto dinero de pérdidas le supone a una compañía aérea que su web de venta de billetes por internet esté caída durante 5 horas en plena campaña de Navidad? Se puede tomar como referencia los datos del año anterior para ver cuánto se vendió ese año en esas 5 horas y así hacerse una idea aproximada, pero ¿cómo calcular las pérdidas a medio plazo por la pérdida de confianza de los clientes? ¿cómo valorar el daño a la imagen de marca? Además, aquí debería sumarse el dinero perdido en reclamaciones, indemnizaciones, etc.

Entonces, ¿se debería realizar testing sobre un software de forma indefinida para evitar los costes de la no calidad? No. Llega un momento en el que el coste del testing es superior al coste que tendría reparar un defecto en producción. Por ejemplo, si se mantiene a un equipo de 20 testers probando una aplicación para que encuentren un defecto menor cada mes, estamos pagando un precio muy elevado por la calidad. Sería más económico el precio de la no calidad. Hay un punto en el cuál los costes de la calidad y la no calidad se cortan y ese punto es el punto óptimo o punto de equilibrio.

¿Y cómo se puede alcanzar dicho punto de equilibrio a un coste bajo? Desde luego, no considerando al testing como una simple ejecución de casos de prueba. El testing comienza mucho antes de la ejecución y termina mucho después. Estas son algunas ideas (hay muchísimas más) para mejorar la eficiencia y la eficacia del proceso de testing:

  • Incluir al cliente en la toma de decisiones de la estrategia de testing. El cliente conoce mejor que nadie su negocio y sus prioridades. La opinión del cliente es fundamental para realizar un análisis de riesgos que permitir determinar el cobertura y profundidad de las pruebas para cada parte del software y para establecer los pilares fundamentales de la estrategia de pruebas.
  • Evaluar los procesos de pruebas para encontrar aquellos que no aportan todo el valor que deberían y mejorarlos.
  • Realizar un proceso de verificación y validación que permita en todo momento saber si se está realizando el producto requerido de la forma requerida.
  • Dejar que el testing se convierta en el centro de la organización. Por su trabajo, el tester tiene conocimiento de toda la aplicación, de los entornos, de la documentación, etc. y puede ayudar y aconsejar con su conocimiento al resto del equipo.
  • Mantener informados en todo momento a los interesados del proyecto dando un visión clara de la calidad del producto apoyándose en métricas objetivas y verdaderamente útiles para cada interesado. Ofrecer información que nadie entiende u ofrecer la misma a todos los interesados es una mala estrategia. El analista no está interesado en los mismos datos que el jefe de proyecto o que el director de la compañía.
  • Probar más no es probar mejor. Piensa en el tipo de software que se quiere probar. Piensa en en la funcionalidad y en la complejidad de la tecnología subyacente. Piensa en los objetivos del software, el usuario final, los requisitos funcionales y no funcionales. Piensa en la probabilidad de fallo y en el impacto en el negocio que tendría descubrir un defecto en el software en producción. Piensa en la cobertura y la profundidad de las pruebas. Piensa en el tiempo, el presupuesto y los recursos disponibles, en su experiencia, habilidades, conocimientos, motivación y compromiso. Piensa en todo ello y entonces, sólo entonces, comienza a diseñar casos de prueba.
  • No probar siempre lo mismo porque llegará un momento en el que no se encuentren más defectos y se esté literalmente perdiendo tiempo y dinero.
  • No probar siempre igual. Hay que adaptarse al cliente, al sector en el que desarrolla su actividad, a la tecnología en la que se sustenta el software, a la mayor o menor calidad de la base de pruebas, etc.
  • Preguntar, preguntar y volver a preguntar… nunca hay que quedarse con una duda porque una duda funcional esconde muy posiblemente un futuro error en producción.
  • Encontrar los defectos cuanto antes porque el coste de repararlos será mayor cuanto más cerca se esté de producción. Si el defecto se encuentra en la fase de toma de requisitos el coste supone unos pocos minutos de tiempo invertidos en actualizar un documento. Si el defecto se encuentra en preproducción a pocos días de la fecha de entrega puede suponer la reescritura del código, el cambio en el diseño técnico y funcional, la modificación de los requisitos, más tiempo de ejecución de casos de prueba, guardias, retrasos (con su correspondiente penalización por el retraso), etc.
  • Documentar, informar, dar visibilidad al trabajo realizado. Guardar aquello que pueda servir para proyectos futuros o para futuras fases de ese mismo proyecto. La información es un activo de las organizaciones y un ahorro de costes en el futuro.

 

En definitiva: el testing es fundamental y es una inversión de tiempo y dinero si se planifica correctamente.

Deja un comentario