Si no tengo errores en producción ¿Por qué habría de hacer testing?

Siempre ha sido difícil vender la necesidad de hacer testing sistemáticamente, y sobre todo en ciertas latitudes del mundo. Pero resulta más complicado aún cuando, además, no hay errores en el ambiente de producción [1].

Parte de la explicación puede encontrarse en esa idea de que “no hay nada mejor para facilitar un cambio que una buena crisis”. En un contexto en el que se debe tomar la decisión inicial de introducir actividades de testing de software en un área de desarrollo o no, tener problemas en el ambiente productivo inclina la balanza hacia el sí.

Dado un proceso de desarrollo que produce software con bajo nivel de errores en producción – es decir que el usuario no tiene grandes quejas respecto a lo entregado – ¿por qué sería necesario encarecer los costos del proceso introduciendo nuevos controles?

A continuación ofrezco 3 argumentos:

• El primer argumento es el de la disminución de riesgo potencial. El hecho de tener un proceso de desarrollo que no haya producido software defectuoso hasta el momento, no garantiza que esos resultados a futuro. En muchas situaciones la actividad de testing se concibe como un seguro que uno paga para “cubrirse” de posibles siniestros que pudieran ocurrir en el futuro.
• El segundo argumento es el de entrenar al equipo y estar preparado para desafíos mayores. Tal vez el equipo de desarrollo funcione bien para cierto tipo de proyectos conocidos pero ¿qué pasa si los proyectos futuros tienen características nuevas? Otra vez: el éxito en los proyectos pasados no necesariamente es un buen estimador del nivel de éxito futuro. Tener incorporada la disciplina de controlar la calidad en proyectos conocidos permite encarar proyectos más complejos con mayor certidumbre, o dicho de otra forma, aprender a manejar en una autopista parece ser peor idea que hacerlo en una calle aislada. Practicamos en calles aisladas para luego ir a la autopista.
• El tercer argumento es el del testing como observatorio metodológico. Tener un punto de control como el testing permite observar el proceso de desarrollo y, eventualmente, tomar decisiones o hacer cambios que lo potencien o mejoren. Inclusive que nos permitan ahorrar tiempo del personal suprimiendo acciones que no agregan valor o agregando otras que lo incrementen.

Seguimos pensando..

[1] El ambiente productivo (o de producción) es el ambiente donde se ejecuta el software y se contienen los datos reales de la organización. Las buenas prácticas de desarrollo de software indican que el ambiente productivo debe estar separado del ambiente de desarrollo de software y del de testeo.