Cuando iniciamos en el mundo del desarrollo de software, generalmente estamos muy enfocados en hacer que una característica funcione, o arreglar un bug y dedicamos tiempo en un ciclo de: pruebo manualmente lo que los usuarios me piden, funciona? no, verifico que cambios necesito, hago los cambios en el código y vuelvo a probar que el requerimiento funciona, funciona? si, lo pongo en producción.

Este ciclo de desarrollo está bien para proyectos pequeños que se van a quedar pequeños, y no críticos. El problema está en que no somos adivinos y no podemos saber a futuro que lo que estamos desarrollando va a quedarse pequeño y no crítico para el negocio.

Generalmente no pasa eso, los desarrollos se realizan por algo y mientras más se usa más crítico se vuelve. Por esta razón es importante desde los inicios de un nuevo proyecto tener una infraestructura adecuada para tener pruebas automatizadas que las puedan ejecutar los desarrolladores localmente, y también se puedan ejecutar en los sistemas de integración continua. Adicional a pruebas automáticas es muy importante mantener pruebas manuales ya que las pruebas automáticas generalmente sólo verifican lo que el desarrollador piensa que se debe probar.

Debido a que este tema es muy amplio, voy a escribir una serie de artículos que cubren diferentes conceptos acerca del desarrollo de software basado en pruebas. Para iniciar comencemos por lo básico:

¿Qué son pruebas de software?

Las pruebas de software, son procesos cíclicos que permiten a los desarrolladores verificar si un requerimiento o cambio en el sistema es correcto o no. Adicionalmente permite verificar que una versión específica del software tenga todos los requerimientos solicitados. También pueden ayudar a verificar que el software puede funcionar correctamente en diferentes medios o con diferentes integraciones, como por ejemplo en diferentes sistemas operativos, o en diferentes versiones de software base.

¿Por qué son importantes las pruebas de software?

Sin pruebas me parece que es imposible conocer si estamos haciendo algo correcto, no creo que nadie pueda simplemente cambiar código y ponerlo en producción sin siquiera verificar en su ambiente que el cambio hace lo que debe hacer.

Aún en ambientes donde no se tienen pruebas automatizadas, las pruebas manuales son la única forma de verificación de que el software funcione luego de realizar un cambio, y son válidas pero estas no escalan con el software y su complejidad.

¿Cómo funcionan las pruebas de software?

Hay muchas formas de probar software, tenemos pruebas manuales, pruebas automáticas unitarias, de integración, aceptación, etc.

Generalmente los desarrolladores primero deciden qué comportamiento o característica requiere una validación, planifican cómo se puede verificar que el software funciona como se detalla, crea un script de prueba para verificar y ejecuta este script cada vez que hace cambios en el código hasta confirmar que funciona.

La parte de “crear un script de prueba”, es así tanto para pruebas manuales o automáticas, la diferencia radica en que para las manuales lo crea en su mente y en las automáticas lo crea en un archivo de código. Cómo pueden ir viendo las pruebas manuales cumplen el mismo papel que las automáticas pero de la forma en la que se crean no se pueden compartir con el equipo de trabajo y son muy lentas en ejecutar.

Beneficios de pruebas en el software

Asegura funcionalidad completa Asegura que todos los requerimientos desarrollados estén presentes en el producto final.

Alerta temprana Permite saber muy temprano en el desarrollo de software acerca de defectos que pueden afectar negativamente al usuario.

Reconstrucción de código Si tenemos un conjunto de pruebas muy amplio, es mucho más fácil hacer reconstrucciones internas del código para mejorar arquitectura sin afectar al usuario final.

Estos son algunos de los beneficios, debe haber muchos más. Pero lo más importante que me gustaría compartir es que las pruebas son muy críticas en el desarrollo, y que está bien si lo hace manualmente por ahora, pero que deben comenzar a planificar un cambio en sus mentes y en sus procesos para incorporar pruebas automáticas, al principio es muy duro van a pensar que escribir los tests los hace más lentos, que no son importantes, que hacen más complejo el desarrollo, pero una vez interiorizado el desarrollo con pruebas automáticas van a ver atrás y preguntarse ¿cómo realizaron tantos sistemas sin pruebas automáticas? Les va a parecer una locura. Sí tienen que cruzar ese valle oscuro, pero al otro lado hay cosas muy buenas, como tranquilidad de que no vas a dañar nada en producción, aumentar la calidad de tus productos para que el cliente ya no sea el departamento de QA.