Las 7 desventajas al no probar un proyecto de software

proyecto de software

proyecto de software

Aunque es normal que al acercarse el final de cada ciclo de desarrollo se intensifique el esfuerzo de pruebas (especialmente las

manuales), es un error mayúsculo no haber probado desde el principio del desarrollo. Esto no es un tópico o una consideración teórica o académica: no probar desde el principio del ciclo de desarrollo tiene muchas desventajas. Por ejemplo:

 

  1. El esfuerzo mental de probar un programa grande es mucho mayor que el esfuerzo de probar un programa pequeño. No se sabe por dónde empezar, es difícil saber cuándo terminar, y es fácil quedarse con la sensación de que no todo está probado correctamente. Si probamos los componentes que vamos creando desde el principio, es mucho más fácil saber cómo atacar el problema y hacer pruebas más completas.

 

  1. Si probamos mientras escribimos código y sabemos el nivel de calidad de éste, será más fácil hacer estimaciones sobre los recursos necesarios para terminar el resto del trabajo. Esto nos dará mucha más flexibilidad para renegociar fechas o las características que se tendrán que quedar fuera, en vez de pasar al estado de alarma cuando nos demos cuenta, demasiado tarde, de que no tenemos tiempo de arreglar los fallos que encontremos los últimos días.

 

  1. Cuando hemos «terminado» un proyecto y sólo queda probar, es normal tener la tendencia a «no querer ver fallos» o restarles importancia, a que nos inunde un falso optimismo que confirme que de verdad hemos terminado y no queda nada por hacer. Sobre todo si quedan pocos días hasta la entrega y sentimos que no podemos hacer gran cosa, y sólo queremos entregar el resultado y olvidarnos del proyecto. Esto ocurre mucho menos si tenemos a profesionales exclusivamente dedicados a las pruebas, claro.

 

  1. Probar desde el principio significa que estaremos probando durante más tiempo, por lo que habremos encontrado más casos que puedan ser problemáticos, y por tanto más fallos (y las soluciones a éstos), antes de que sea demasiado tarde.

 

  1. Todas las pruebas que hagamos pronto ayudarán a aumentar la calidad del código, lo que no sólo afecta a la calidad final del producto, sino a lo fácil que es escribir y depurar cualquier otro código que dependa del primero. Los fallos de interacción entre las dos bases de código serán más fáciles de encontrar y, en particular, la fuente de los errores.

 

  1. Si desde el principio escribimos pruebas automáticas, nos obligaremos a nosotros mismos a escribir APIs más limpias. Generalmente, código más fácil de probar es código más desacoplado, más limpio y más estable. Indudablemente, una de las ventajas de escribir pruebas automáticas es que ayudan a mantener un diseño de mayor calidad. Pero si no probamos desde el principio, perdemos esta ventaja.

 

  1. Al no probar desde el principio, desarrollaremos código que no es especialmente fácil de probar, y cuanto más tarde empecemos a adaptar el código para que lo sea, más esfuerzo costará. Una vez hayamos escrito una gran cantidad de código sin tener en cuenta si es fácil de probar o no, la tentación de dejar muchas partes sin pruebas será irresistible. Y, por supuesto, si no hacemos el esfuerzo de adaptar el código en ese momento, entraremos en un círculo vicioso.