La relevancia de las pruebas automáticas de software para cualquier empresa 🧪

Hace unos días en mi trabajo tuve un intercambio con otro miembro del equipo de liderazgo que surgió debido a que leyó un artículo de un fundador y emprendedor que menciona que no hay que enfocarse mucho en las pruebas automáticas cuando no se es una empresa grande.

Aunque entiendo el dilema al que uno se enfrenta cuando se está comenzando una ruta y la incertidumbre acerca de hacia dónde debe dirigirse el producto, estoy en total desacuerdo con dicho planteamiento.

En mi opinión integrar pruebas desde el comienzo es lo más sano en el ciclo de desarrollo y por lo tanto en el ciclo de cualquier empresa de software. Las razones principales son:

1. Permite razonar correctamente acerca de la implementación del software.

La recomendación que les doy a los miembros de mi equipo de desarrollo es que antes de comenzar a trabajar en cualquier implementación se hagan la pregunta ¿Cómo voy a probar esto?

Esta permite que pensemos un poco antes de intentar implementar. Con ella podemos razonar acerca de 1) la entrada de datos, 2) los módulos involucrados, 3) las invocaciones e instancias, 4) las situaciones en los extremos de los parámetros y 5) la salida de datos y su representación.

Al estar al tanto de estos elementos y poder expresarlos en buena forma para ser probados automáticamente estamos más al tanto de lo que optamos para nuestra implementación.

2. Permite integrar estándares de calidad en el producto

Una mejor calidad en el software es tarea de todos los que participan en el ejercicio de la implementación y se traduce directamente en satisfacción por parte del usuario.

Integrar pruebas automáticas correctas crea arneses alrededor del producto ya que con cada lanzamiento estamos seguros que cubrimos ciertos estándares de calidad que se han fijado.

Al optar deliberadamente por integrar calidad en el desarrollo el equipo se puede enfocar mucho más en mejorar ciertas características o en crear nuevas funcionalidades para el producto más que en resolver fallos.

3. Permite crear contratos con los usuarios

En mi opinión la mejor manera de escribir pruebas automáticas del software es invocando nuestro sistema desde la perspectiva del usuario final, creando de esta manera contratos con ellos. Por ejemplo para una API implica invocar directamente nuestras rutas y evitar realizar pruebas para funciones intermedias.

Cuando en un momento posterior del desarrollo detectamos que una prueba está fallando ante un cambio introducido recientemente podemos atender el caso sabiendo que muy probablemente tendremos una queja por parte de nuestros clientes.

4. Permite crear documentación sobre el producto

La documentación del software es un tema que tiene muchas aristas. También he observado que crea ciertos apegos personales ya que no existe un estilo estandarizado para hacerlo. Aún así considero que una de las mejores formas de documentar un producto, desde el punto de vista de un ingeniero de software, es mediante las pruebas automáticas que tiene integradas.

Con estas obtenemos información acerca de los datos de entrada, cuáles son los casos esperados, cómo se expresan y manejan los errores, así como sobre los datos de salida. En el caso de interfaces de usuario permite observar cuáles son los flujos de navegación que un usuario puede experimentar en el producto, qué llamadas realizan dichos flujos y qué ofrecemos como diálogos y manejo de excepciones.

Con esto se incrementa también la habilidad de integrar nuevos miembros en el equipo en un tiempo corto.


Dado lo anterior, la importancia de las pruebas automáticas es relevante para toda empresa sin importar la etapa en la que se encuentre. El punto está en encontrar velocidad y no interrumpir la habilidad para el lanzamiento de nuestros productos.

Aquí velocidad también implica****velocidad en la habilidad de escribir pruebas automáticas junto con el código, por lo tanto considero que se debe invertir adecuadamente en:

  1. Crear una cultura del desarrollo de software con pruebas automáticas. Quizás TDD sea mucho para algunos miembros, lo más importante es que todos estén de acuerdo en lo importante que es escribir dichas pruebas.
  2. Construir sistemas de integración y lanzamiento continuo (CI/CD) que realicen pruebas automáticas previo a integrar nuevo código y más pruebas posteriores a dicho evento.
  3. Adecuados sistemas de pruebas automáticas que nos permitan escribirlas sin dificultad. Frameworks como jest o mocha son buenos ejemplos para javascript y typescript. Para aplicaciones web existen también herramientas como cypress y nightwatch en el frontend. Lo sano es identificar qué nos conviene más dependiendo de las características de nuestro sistema.
  4. Entrenar a los miembros de equipo en dichos sistemas. A veces no existen entrenamientos oficiales y por tanto permitir incrementar la familiaridad mediante la experimentación directa es de igual importancia.
  5. Revisiones conjuntas del equipo que incluyan los tests. El equipo debe tener la tarea de cuestionar no sólo el código sino también la forma en que está siendo probado.

Todo lo anterior es una tarea progresiva. La idea es mantener la mira en los cuatro puntos mencionados anteriormente y poco a poco mejorar como equipo.

Optar por integrar pruebas automáticas desde el principio tiene grandes retribuciones en el futuro 😉