¿Qué Cambió en Testing?

La evolución del software llevó a cambiar la forma de testear. Si bien la única manera de garantizar que una aplicación funcione es testear la misma y comprobar su resultado. La forma de realizar el “Como” cambió enormemente.

Una de las principales dificultades que existen cuando se implementa una nueva versión de software es que se debe hacer un test de regresión. Ya que es necesario volver a probar todas las funcionalidades, donde a decir verdad la mayoría de las veces no ocurre, sino que se testea solo la nueva funcionalidad. Varios días después de pasarlo a producción, sale a la luz que la funcionalidad nueva generó errores en funcionalidades existentes, no siendo detectado por el proceso de testing debido a que se probó solamente lo nuevo.

Tampoco suena lógico que cada cambio que se realice se tenga que hacer testing de regresión para “re-testear” toda la aplicación, ya que en este caso el testing se convertiría en un “cuello de botella” por la cantidad de horas que insume cada ciclo de testing. Llevado a la práctica muchas veces sucede que las pantallas que “siempre funcionaron bien” tienden a no probarse como es debido, y el resultado es un reporte de casos de prueba que no termina siendo real.

Para mitigar esto mismo lo primero en aparecer fueron los Unit Tests donde se programa el llamado a una función y se compara el resultado según el esperado. De esta forma se garantiza que las pruebas fueran realizadas de una determinada manera. En algunos casos es efectivo, pero está lejos de reflejar lo que el usuario realiza desde la pantalla de la aplicación, ya que el Test Unitario accede de distinta forma al usuario sin poder garantizar la funcionalidad. Además otro problema que tienen es que realizar un test por cada función es muy costoso para el proyecto.

Hoy en día se encuentran herramientas como Selenium, Appium y jMeter que permiten realizar pruebas automáticas de forma mucho más ágil  tal cual como lo haría un usuario y mostrar un reporte con el resultado de las mismas. Otra herramienta importante es SonarQube, donde se recorre todo el código fuente para detectar Code Smells, código duplicado, código fuera de uso, vulnerabilidades y hasta evalúa la calidad del Software. Teniendo un barrido de estado del software y marcando exactamente donde se encuentra cada punto critico en el código fuente.

Por último Jenkins aporta un condimento más a la solución, permite automatizar cada deploy para que despierte un proceso que ejecute todos los test automatizados, prepare un reporte y notifique a los interesados sobre los últimos cambios e inconsistencias que se pueden presentar.

En Fusap utilizamos estas herramientas en varios proyectos, optimizando el tiempo de testing, asegurando de cumplir con la pruebas necesarias y obteniendo un reporte de resultados en cada actualización del software.

Agustín Chermaz