archivo

Archivo de la etiqueta: Doug Linder

Este antipatrón surge en aquellos casos en los que los desarrolladores (o el equipo de desarrollo) dan por correctas determinadas funcionalidades sin haber pasado el suficiente número de casos de prueba que permitan testearlas teniendo en cuenta diversas casuísticas en los juegos de datos, en la interacción con terceros sistemas o en la propia operativa del usuario.

El testing de fogueo es una de las causas que provocan que un mayor número de defectos se detecten más tarde de lo que debieran, como por ejemplo en la integración con otros módulos, con otros sistemas o incluso en producción.

Aplicando testing de fogueo se obtiene una imagen del estado del proceso de desarrollo que no se corresponde con la realidad, por eso insisto mucho en que las funcionalidades tienen que estar bien probadas porque de lo contrario se crean expectativas en cuanto al avance de los trabajos que pueden provocar que, cuando nos demos cuenta de los problemas, sea demasiado tarde para reaccionar.

No se debe confundir con el antipatrón: “No probado pero finalizado, ya que este tipo de prácticas no son necesariamente provocadas por la necesidad de cumplir unos plazos más o menos complicados, sino que vienen “de serie” con los desarrolladores.

Ya lo decía Doug Linder: “Un buen programador es aquel que siempre mira a ambos lados antes de cruzar una calle que tiene un único sentido“.

Confianza ciega, un problema que afecta a una gran cantidad de programadores, no haciendo caso a una cita de Doug Linder que indica una de las características fundamentales que debe tener un buen programador: “Un buen programador es aquel que siempre mira a ambos lados antes de cruzar una calle que tiene un único sentido”.

Confianza ciega es todo lo contrario. Se desarrolla una funcionalidad o se corrige una incidencia y no se prueba lo suficiente y/o no se tienen en cuenta efectos colaterales.

Siempre hay que hacer testing, lo mismo te parece una pérdida de tiempo, pero a la larga, haciendo sumas y restas, será mucho más el tiempo de desarrollo que te has ahorrado que el que has invertido haciendo pruebas.

Sucede con demasiada frecuencia que cuando se entrega una evolución de un software, ya sea en una iteración en un desarrollo iterativo incremental o en un mantenimiento correctivo o evolutivo, se realiza testing exclusivamente sobre las funcionalidades que se han desarrollado y no se comprueban otros segmentos del programa que se han podido ver afectados por los cambios realizados en el código.

En muchos casos son las prisas por cumplir plazos en el proyecto, en otros por la necesidad de solucionar una urgencia y en otros tantos porque no se piensa que determinados cambios en el código puedan provocar efectos colaterales en la aplicación.

Las posibilidades de que se produzcan este tipo de problemas dependerá mucho de la calidad de la codificación y de la sección del código que se esté tocando, ya que no es lo mismo tocar una clase con un alto acoplamiento que otra.

Para reducir el riesgo de que aparezcan efectos colaterales, es conveniente la realización de pruebas de regresión que se basan principalmente en realizar testing sobre funcionalidades de la aplicación que presentan riesgo de haber sido afectadas por los cambios. El esfuerzo necesario en realizar estas pruebas dependerá del nivel de automatización de las mismas que se tenga hasta el momento en el rango que va desde las pruebas unitarias hasta las funcionales.

Sobre las pruebas de regresión y en general sobre el hecho de que en la programación no hay que dar nada por sentado, podemos recordar la siguiente cita de Doug Linder: “Un buen programador es aquel que siempre mira a ambos lados antes de cruzar una calle que tiene un único sentido”.

El administrador de sistemas americano, Doug Linder, comentó que: “Un buen programador es aquel que siempre mira a ambos lados antes de cruzar una calle que tiene un único sentido”.

Me parece una cualidad excelente para un programador que no dé las cosas por sentado, que no piense que todo lo que está desarrollando va a funcionar a la primera y que, por tanto, no hay que revisar constantemente lo que se está haciendo. Para entregar un buen trabajo, hay que probar, hay que depurar y así hasta que se tenga una seguridad de que lo que se ha hecho funciona.

Puede parecer que se trata de una exageración, pero no lo es, uno de los principales problemas de los programadores es que no prueban lo suficientemente bien lo que están haciendo (puede haber otros problemas relacionados con aspectos técnicos de calidad del código, eficiencia, productividad, etc… y que como es lógico hay programadores que tienen pocos defectos y otros que tienen muchos más), de hecho, ¿quién no conoce casos donde se han hecho una serie de clases que se han entregado y ni han compilado o qué compilando empiezan a fallar por todos lados? y esto es algo que no solo sufrimos los clientes, sino que también sufren los compañeros del equipo de proyecto que tienen que enfrentarse a esas desaplicaciones cuando tratan de integrar módulos del programa o hacen una revisión previa a la entrega del cliente.

¿Qué se pueden escapar cosas? Es lógico que no se consigan detectar todos los problemas, pero es absolutamente necesario intentar encontrar y solucionar todos aquellos que sean posibles, ya que el esfuerzo y coste de corregirlos en etapas posteriores del desarrollo es mucho mayor.