La importancia de entregar los productos software al cliente muy bien probados

Si para cumplir los plazos de un proyecto se entrega sea como sea y esté como esté un producto software al cliente no supone ninguna solución, es más, si lo que se entrega presenta muchos errores y una calidad deficiente es casi peor el remedio que la enfermedad. Esto todavía es de una mayor gravedad si encima se actúa de la misma manera cuando se está fuera de plazo.
Es demasiado frecuente encontrarnos con que las empresas de desarrollo de software no prueban lo suficientemente bien los productos antes de entregarlos, se limitan a hacer unas cuantas pruebas de rutina y ya consideran que está todo lo suficientemente bien, como para para realizar la entrega.
Hace poco, un compañero me comentó que había una empresa que le había gustado especialmente, porque todo lo que le entregaba prácticamente no tenía errores, lo que agilizaba muchísimo el paso a producción y daba pocos quebraderos de cabeza posteriormente en el entorno de producción. Esta situación que debería ser una norma para el conjunto de desarrollos que nos llegan, no es así, lo que provoca que cuando se hacen las cosas como deberían ser parecen hechos extraordinarios y excepcionales.
Si un producto se entrega con el menor número posible de errores es bueno para el cliente, pero todavía lo es más para el proveedor.
Motivos:
1) Aunque simplemente sea un ingrediente más de la calidad del software, entregar un producto que prácticamente no falla (tanto a nivel funcional como no funcional) habla bastante bien de la empresa que lo ha entregado. Además, si se llega a esta dinámica es porque realmente se están haciendo las cosas bien en el proveedor a nivel procedimental y metodologico, es decir, se ha diseñado y ejecutado internamente un plan de pruebas, de calidad, que probablemente habrá sido resultado de una fase de análisis y diseño que se ha ejecutado y documentado correctamente. Además, se conocerá el entorno tecnológico del cliente, se tendrá documentado y probablemente incluso se habrá intentado replicar hasta donde haya sido posible y se sabrá cómo se realiza el procedimiento de paso a pruebas y producción que utiliza.
Los clientes no queremos problemas, no queremos que el proceso de paso a producción sea eterno, no queremos que la implantación nos robe más y más tiempo y por supuesto, no queremos que el producto empiece a fallar en producción por todos lados. Como no queremos problemas, se tiende a valorar muchísimo más todo aquello que no los da.
2) Para un cliente entregar un producto con muchas incidencias y empezar a parchearlo una y otra vez, hasta tener un producto estable, cuesta mucho más esfuerzo y por tanto dinero que habíendolo entregado existiendo un procedimiento serio de pruebas del producto. Si bien de esta segunda manera puede parecer más costoso entregar el producto (de hecho lo es), al final y haciendo cuentas es mucho más barato que tener que estar corrigiendo incidencias y pasando las mismas a pruebas y a producción en distintas iteraciones. Además, entre iteración e iteración se incrementa el riesgo de que se intenten colar mantenimientos evolutivos como correctivos (aprovechando la débil frontera que existe en ocasiones entre ambos y en muchos casos la escasa documentación de los proyectos y de la ausencia de actas de reunión), lo que a su vez complicará muchísimo más todo y disparará, en consecuencia, los costes.

http://jummp.wordpress.com/2010/03/08/la-importancia-de-entregar-los-productos-software-al-cliente-muy-bien-probados/