archivo

Archivo de la etiqueta: Boris Beizer

Se hace testing para detectar defectos, por tanto, tendrán éxito cuando cumplen su propósito. Esta es la visión de Boris Beizer en la siguiente reflexión: “Un test que revela un bug ha sido exitoso, no al revés”.

Podemos centrar el testing en secciones del código o en funcionalidades donde existe menos probabilidad de que existan defectos y probablemente no estemos aprovechando de manera adecuada el esfuerzo o, al menos, no con la rentabilidad que supondría enfocarlo de manera adecuada.

Una versión de lo anterior es hacer un testing “cómodo” para cubrir el expediente, sin entrar en tareas de mayor profundidad.

La función del testing es encontrar errores, dado que los desarrolladores no somos infalibles, si no se detectan defectos deberíamos plantearnos si efectivamente el testing que estamos haciendo está siendo efectivo, sobre todo si después comprobamos cómo van llegando a producción en una proporción muy superior a la que debería ser y/o a la inversión realizada.

Siempre en el peor momento y después toca correr para corregirlas. El problema es cuando no hay espacio para frenar y tras él solo queda el abismo.

No somos infalibles, de hecho no debemos serlo, salvo que el sistema sea tan crítico como para que de él dependan vidas humanas o se comprometa la viabilidad económica o de negocio de una organización. Pero una cosa es saber que cometeremos errores, aceptar un determinado umbral adecuado a las características del proyecto y su presupuesto y otra que esas incidencias se produzcan de forma sistemática.

Se ha convertido ya en algo comúnmente aceptado que las entregas no sean limpias y que se tenga que iterar varias veces hasta alcanzar una versión aceptable para pasar a producción, cuando no iterar sobre versiones que han llegado a producción.

Os lo aseguro, vale la pena hacer testing (bien hecho), invertir esfuerzo en ello, el que sea necesario.

Cuántas veces se me viene a la cabeza la famosa cita de Boris Beizer: “Una amenaza bien vale mil pruebas“.

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.