archivo

Archivos diarios: julio 28, 2011

Boris Beizer es un autor e ingeniero de software americano (aunque nacido en Bélgica) especializado en el campo de la calidad del software y del testing. Sus primeras publicaciones datan de finales de la década de los cincuenta, aunque su etapa más prolífica fue en las décadas de los setenta y de los ochenta.

El testing es un campo dentro de la ingeniería del software un tanto controvertido. La mayoría de los profesionales consideramos necesarias las pruebas en el proyecto de desarrollo de software, si bien no hay coincidencia en cuanto a la intensidad, los momentos y la metodología.

Soy de la opinión de que no todos los proyectos y sistemas de información deben tener un mismo tratamiento y que independientemente de que exista una cierta metodología en las pruebas, estas deben girar alrededor del testing ágil y del exploratorio.

También soy partidario de que las clases con mayor acoplamiento sean cubiertas mediante pruebas unitarias (no necesariamente desarrollando según técnicas de desarrollo guiadas por las pruebas (TDD)) y que se deben minimizar los efectos colaterales a través de las pruebas de regresión.

En cuanto a los momentos, el testing debe aplicarse desde las etapas más tempranas del software, si bien los actores pueden ser distintos a las pruebas realizadas sobre el producto.

Y como estrategia, la utilización de integración continua permite detectar problemas de carácter unitario y de integración lo antes posible y a reducir los problemas en la fase de implantación.

Boris Beizer realiza la siguiente reflexión (traducción libre): “Una amenaza bien vale mil pruebas”.

Desgraciadamente nos acordamos de un proceso de testing bien realizado cuando ya los errores han salido a la luz y lo peor de eso, cuando su corrección requiere de un esfuerzo considerable, cuando ha impactado gravemente en el negocio o cuando nos crea un problema.

Cuando mayor sea la criticidad del sistema más peso debe tener el proceso de testing y más peso debe cobrar la metodología y sistematización.

En aquellos casos donde se sabe que el proyecto es un Death March Project (y hay casos donde es evidente que es así) probablemente no tengamos más remedio que participar en esa locura. Al fin y al cabo no somos más que empleados de una organización y necesitamos nuestro puesto de trabajo.

Sin embargo, habrá ocasiones donde sí podamos tener algún tipo de influencia para evitar esta situación o por lo menos, paliarla. Si tenemos esta oportunidad y nos quedamos callados seremos cómplices. Como profesionales queremos que los proyectos se ejecuten con éxito, si aceptamos de antemano uno que va directo al fracaso, atentamos contra aquello en lo que creemos y además nos estamos encargando de apretar nuestra propia soga.