Las pruebas no son una opción en el desarrollo de software.

¿Cómo es posible que algo empiece a fallar sino ha sufrido cambio alguno?

     Seguro que, si te dedicas o te has dedicado en tu vida laboral, en algún momento, a temas relacionados con la calidad del software te has hecho esta pregunta. Y seguro que, una vez que has comprendido que cualquier cambio en el código de una aplicación, por pequeño e inofensivo que parezca, puede tener consecuencias inesperadas, te has hecho esta otra.

¿Cómo garantizo que las partes que funcionaban siguen funcionando igual que lo hacían?

     A este efecto, en el que el software falla en alguna de las partes que han permanecido inalteradas, después de un cambio o ampliación, se le denomina regresión, y a probarlo se le denomina hacer pruebas de regresión.

Cuando hacemos pruebas de regresión, estamos comprobando varías cosas, cada vez que ejecutamos las pruebas:

•  Comprobamos que el código que hemos modificado se comporta como debe.
•  Comprobamos que el cambio realizado no ha causado problemas a otras partes del código.
•  Comprobamos que errores detectados y corregidos, no vuelven a aparecer.

Tener software, sin pruebas, es garantía de problemas.

    Si no te has encontrado ya, te garantizo que te encontrarás, en la situación de tener que ampliar y/o modificar software que ha estado tiempo inalterado, incluso habiéndolo desarrollado tú mismo, que no reconocerás y que, dime algo, cómo “meterás mano a este código” sin estar seguro de que lo que no “toques” seguirá funcionando.

     Recuerda algo, puedes tener el mejor software del mundo, que si falla darás una impresión muy pobre. Por este motivo, las pruebas de regresión son una pieza esencial en cualquier ciclo de desarrollo de software.

     Además, a medida que el proyecto avanza, la batería de pruebas de regresión cada se hace más y más grande, llegando a consumir mucho tiempo, y en un mundo claramente dominado por la tendencia a la reducción en los tiempos de desarrollo, el esfuerzo disponible para realizar pruebas se ve irremediablemente reducido, transformando a la estrategia y planificación de pruebas, en uno de los mayores retos de la industria de la calidad del software.

Por todos estos motivos, haz pruebas siempre, al principio realiza pruebas básicas, pequeñas, pero déjalas programadas, te ayudarán a entregar código de calidad.