El valor del testing en el negocio

Merece la pena recordar los términos "Cost of Quality" y "Cost of Poor Quality".
Basicamente el Coste de Calidad es lo que se invierte en testing y gestión de defectos mientras que el Coste de la Pobre Calidad es lo que nos cuesta resolver los defectos + el impacto de estos




El Coste de la calidad es medible de forma directa 


COQ = tiempo * Esfuerzo invertido


El Coste de la pobre calidad sólo puede ser estimado 


CPQ = tiempo en resolver los defectos * Esfuerzo de desarrollo * Impacto en imagen + Impacto en los clientes + Penalizaciones por incumplimiento del servicio.


Suele salir rentable la inversión en calidad como tal, puesto que el coste de la "Poor Quality" ronda el N-veces la inversión en calidad.


Algunas "Malas prácticas" al respecto:
- Deja de estar "de moda" el testing y es el primer sitio de donde recortar, se delega en la responsabilidad de cada developer y en el ownership. Como punto positivo es que bien planteado desarrollador y tester son la misma persona, como punto negativo es que es necesario un equipo altamente comprometido, cualificado y sin presiones de negocio... vamos un equipo de universitarios para un proyecto de investigación del que no dependan vidas.
- Outsourcing 100% del equipo de  calidad: el equipo de calidad es un equipo de testers a sueldo que se ciñen a la ejecución de tests y reporte de defectos, sin pensar en la eficiencia.
- Se opta por los riesgos no cuantificables, probables y de alto impacto en vez del gasto controlado y cuantifiacable
- Se consume el tiempo de testing en desarrollar más código sin dar tiempo a la estabilización y se fuerza a reducir al mínimo la parte de pruebas, no porque no se haya pagado el esfuerzo sino que se opta por descartar esos resultados.


¿Alguna más?. 

Buscando el problema (II)

Cómo enfocar la búsqueda del problema:

• Probar primero las cosas que han cambiado
• Probar primero las funcionalidades "core" antes que las agregadas
• Capacidad antes que fiabilidad
• Probar situaciones habituales antes que las condiciones esotéricas
• Probar los problemas con alto impacto antes que los que tienen pocas repercusiones
• Probar las áreas con más interés antes que las menos utilizadas

Y finalmente, lo que ayuda bastante a enfocar el testing eficiente es conocer bien el producto y a los usuarios que lo utilizarán.

Buscando el problema

Es importante ir a buscar el problema y no a encontrarse el problema... hay una gran diferencia.
Ir a buscar el problema es enfocar el testing conociendo el producto, su implementación y la relación con el resto de entidades para que con el subconjunto mínimo de pruebas tengamos cierto nivel de confianza sobre la construcción del producto. Encontrarse el problema es cuestión de suerte.
He conocido a testers con suerte, y creo que es un factor nada despreciable, al contrario, pero que tiene el problema que no sabes cuando te abandonará :)

La intuición es otro amigo invisible que nos acompaña a veces y que bien utilizado puede darnos ciertas ventajas. Si nos apoyamos en la intuición más una estrategia de buscar el problema tendremos la balanza equilibrada entre corazón y cabeza...