2011-02-16

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.

5 comentarios:

  1. Se prodrian agregar los siguientes argumentos:

    · La mayoría de las mejoras de usabilidad y accesibilidad en un producto de software, son sugeridas por el equipo de testing.

    ·Brinda confianza a la compañía a la hora de vender el producto (Venderores respaldados que pueden confiar que su producto no tiene fallas y hace lo que debe hacer)

    · El testing de software es una exelente fuente de información, tal como lo son los reportes de defectos, las metricas y los resultados que asisten al área de IT a realizar planificaciones eficientes.

    ResponderEliminar
  2. Gracias Julio por tu comentario.

    Efectivamente los puntos que mencionas son muy válidos. En particular el tercero está muy relacionado con "mí" tercer argumento.

    Saludos,

    ResponderEliminar
  3. Sabemos por experiencia (seguramente habrá una estadística para citar -- memory cache miss) que aunque no los veamos los errores están ahí, como dice Julio.
    Causas para esto podrían ser que la versión del software esté muy estable, o requiera poco mantenimiento evolutivo, pero si esto no fuese así las causas podrían ser:

    1) que el equipo de desarrollo esté sólidamente empapado del sistema, tanto a nivel técnico como a nivel negocio. Si es este el caso, los equipos no son para siempre, la gente rota, y con nueva gente, nuevas fuentes de bugs :)

    2) Que la actividad de testing de la cual el prospect reniega, sea responsabilidad implicíta del funcional/responsable del aplicativo, lo cual le hace perder tiempo valioso en formular sus pruebas, renegar con los desarrolladores, etc.

    ResponderEliminar
  4. Si mi auto anda bien en la ruta ¿Por qué habría de hacerle revisiones?

    ResponderEliminar
  5. Gracias a ambos por sus comentarios. Me encantó el tuyo Thomas!

    Saludos,
    Ernesto

    ResponderEliminar

Muchas gracias por comentar. Por favor deja tu nombre y/o email, los comentarios son mucho más valiosos cuando se sabe quien los hace.