7 problemas que debes de evitar a la hora de probar un software.

probar-software

probar-software

A la hora de hacer la prueba de nuestro proyecto de software debemos de tomar en cuenta de que tenemos que evitar ciertos problemas que causaran retroceso a nuestro proyecto. A continuación te presentamos 7 problemas que debes de tratar de no cometerlos:

1- Dejar las pruebas para el final

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. Aquí puedes ver 7 desventajas al no hacerlo.

2- Ser demasiado específico en las comprobaciones

Esto es un problema bastante común, sobre todo cuando se empiezan a hacer pruebas. Las pruebas automáticas son, de alguna manera, una descripción de lo que se espera que el programa haga. Una especificación en código, por así decirlo. Como tal, sólo debe describir el comportamiento que esperamos que no cambie. Si somos demasiado específicos o exigentes en las comprobaciones de nuestras pruebas, éstas no sólo evitarán que introduzcamos fallos en el código, sino también que podamos hacer otro tipo de cambios.

3-No ejecutarlas con frecuencia

Las pruebas no son un añadido al código, son parte integrante de éste. Asimismo, ejecutarlas es parte del ciclo normal de desarrollo. Si no las ejecutamos con frecuencia, no van a ser tan efectivas. Primero, porque cuando haya fallos, es probable que sea más de uno. En ese caso, será más difícil encontrar el origen de éstos. ¿Es un solo error el que provoca todos los fallos en las pruebas, uno por cada prueba? Segundo, porque si hemos hecho muchos cambios desde la última vez que ejecutamos las pruebas, tendremos más código que revisar en busca del problema.

4- No facilitar el proceso de pruebas

El apartado sobre ejecutar las pruebas con frecuencia ya mencionaba que las pruebas son parte integrante del código. Aunque no funciona exactamente de la misma manera ni tienen las mismas propiedades, sí que se tienen que mantener con el mismo cuidado y esfuerzo con el que mantenemos el resto del código.

Este apartado hace hincapié en que tenemos que hacer lo posible para facilitar la escritura de pruebas. Éstas no son una necesidad molesta a la que tenemos que dedicar el menor tiempo posible: como parte integrante de nuestro código se merece la misma dedicación que el resto. Así, nuestro código de prueba debe ser legible, conciso y fácil de escribir. Si cuesta escribir pruebas, ya sea en tiempo, esfuerzo mental o líneas de código, tenemos un problema que debemos resolver, ya sea reorganizando código, escribiendo métodos de conveniencia o usando cualquier otra técnica que nos ayude.

Desgraciadamente, muchos desarrolladores piensan que es normal que sea costoso escribir pruebas y no hacen nada por mejorar la situación. En última instancia, esto hace que el equipo escriba menos pruebas, y de peor calidad.

5- Depender de muchos servicios externos

El último consejo es el más avanzado, y es el consejo con el que hay que tener más cuidado al aplicarlo. La tendencia natural al crear entornos de prueba es replicar algo lo más parecido posible al entorno real, usando las mismas bases de datos, los mismos servidores y la misma configuración. Aunque esto tiene sentido y es necesario en pruebas de aceptación y pruebas de integración, puede ser bastante contraproducente en pruebas unitarias y similares, en las que sólo queremos probar componentes relativamente pequeños.

Depender de servicios externos como una base de datos, un servidor web, una cola de tareas, etc. hace que las pruebas sean más frágiles, porque aumentan las posibilidades de que fallen por una mala configuración, en vez de porque hemos encontrado un problema en el código.

Como en la mayoría de los tipos de pruebas, como las unitarias, sólo queremos probar que cierto componente concreto funciona correctamente, no hace falta que lo integremos con el resto de los componentes. En muchos casos, podemos reemplazar esos componentes con versiones «de pega» que se comporten como nos haga falta para cada prueba.

6- Reusar datos de prueba

Cuando empezamos a escribir pruebas, algo que necesitamos con frecuencia son datos iniciales o de prueba (en inglés, fixtures). Si no tenemos una forma fácil de crear esos bancos de datos para cada prueba, tendremos la tentación de tener un solo conjunto de datos iniciales que usaremos en todas las pruebas de nuestro proyecto. Aunque en algunos casos pueda resultar práctico compartir datos de prueba entre algunas pruebas, esta costumbre puede traer un problema añadido.

7- No controlar el entorno

Otro problema bastante común es escribir pruebas sin controlar el entorno en el que se ejecutan. En parte esta (mala) costumbre viene de la creencia de que las pruebas tienen que adaptarse a diferentes circunstancias y ser robustas como los programas que escribimos.

Esto es un malentendido.Volvamos al ejemplo anterior de la aplicación de tareas pendientes. Cuando escribimos las pruebas, los pasos no fueron:

 

  1. Obtener el número de tareas actuales, llamarlo n
  2. Añadir una tarea
  3. Comprobar que el número de tareas actuales es n + 1

Los pasos fueron:

  1. Dejar la base de datos en un estado conocido (en este caso, vacía)
  2. Añadir una tarea
  3. Comprobar que el número de tareas es exactamente