Ventajas y desventajas de las pruebas automatizadas

En los últimos años ha ganado mucha popularidad la automatización de pruebas de software o test automation, como se conoce popularmente por el nombre en inglés, en el ámbito del desarrollo de software. Y su popularidad se basa principalmente en las grandes ventajas que ofrece cuando es aplicado correctamente en las áreas de desarrollo de software. Hoy quiero traerle las ventajas y desventajas de la automatización de las pruebas de software que hemos podido percibir a través de los años.

Ventajas

Confirmación de lo conocido

Uno de los beneficios de la automización de pruebas es validar que nuestras funciones trabajan de acuerdo a las expectativas que hemos desarrollado. Esto funciona especialmente cuando realizamos cambios en una función después de mucho tiempo y podemos capturar esos posibles errores que podemos estar introduciendo en nuestras funciones.

Esas corridas de regresiones automatizadas se encargan de validar nuestra aplicación cuando esta es actualizada, de modo que un nuevo error no sea introducido por error al momento de realizar los ajustes solicitados.

Retroalimentación instantánea

Rápidamente podemos tener un resultado luego de ejecutar las regresiones automatizadas luego que la aplicación es actualizada, permitiendo a los desarrolladores a corregir cualquier error antes de pasar esos cambios a algún ambiente de prueba.

Revisión rápida del sistema

Imagínense tener que recorrer todos los módulos en la interfaz de usuario para revisar que el proceso está funcionando con las expectativas esperadas y conociendo la forma en que los programadores de hoy en día afrontan las pruebas, posiblemente se salten esa parte del desarrollo de sistema. Esta rápida revisión del sistema nos ofrece un poco de seguridad de que el sistema funciona correctamente.

Evita el rebote de situaciones de un área a otra

Cuando se encuentran errores en el área de QA, las tareas son devueltas a programación para que se realicen los ajustes de lugar para volver a probar. Este proceso evita que las tareas se estanquen en un circulo vicioso de revisión.

Mayor integración entre el equipo de QA y Desarrollo

Al tener la automatización de pruebas bien diseñadas, el equipo de QA puede determinar que expectativas tenía el desarrollador y compararla con los requerimientos originales del sistema y determinar si la solución fue la ideal sin tener que involucrarse en tantas pruebas.

Desventajas

Falsa sentido de calidad

Una prueba automatiza está diseñada  para revisar lo que está supuesta a hacer el sistema y como muchos programadores de experiencia conocen, los errores no son provocados por que entendemos que va a pasar. Los errores de los sistemas es la mayor parte del tiempo son inesperados y posiblemente nuestras funciones no han sido programadas para validar y observar esos posibles fallos.

Es cierto que un buen diseño de escenarios de pruebas puede evitar una gran cantidad de errores, o en otras palabras, capturarlos. No obstante, no es menos cierto que los fallos inesperados por conversiones de datos, por data errónea no siempre son definidos en nuestro plan de prueba y mucho menos validados, especialmente por los programadores que le gusta ver sus códigos lo más limpio posible.

No Siempre son Fiables

Una prueba automatizada puede fallar por múltiples razones, así como el programa original. Un escenario mal definido puede arrojar falsas alarmas y se pueden romper por algún cambio de librerías, interfaz de usuario o problemas de red.

Pruebas automatizas no son pruebas

Los programadores odian probar, he visto como hoy en día, los programadores evitan el paso a paso de las pruebas de debug y prefieren descansar en las pruebas automatizadas diseñadas por ellos mismos,  con pocos escenarios posibles o con los escenarios que los requerimientos están esperando, y repetimos, los errores ocurren en escenarios no contemplados.

Esfuerzo de mantenimiento

Las pruebas automatizadas requieren que se le den mantenimientos así como los mismos programas. Por más automatizados que tengamos nuestros escenarios, hay que estar claro, que al esfuerzo de desarrollo inicial hay que sumarle alrededor de un 45% de tiempo adicional en los tiempos de desarrollo más el tiempo que conlleva hacer los ajustes de lugar cuando se requiere ajustar la aplicación.

Algunas pruebas con el tiempo se vuelven irrelevantes para la aplicación y tenemos que reajustar los cambios realizados y mantener nuestra librería de prueba automatizadas.

Conclusión

Para finalizar, las mayorías de los errores son encontrados por "accidentes" o por incongruencias en la data de los sistemas de producción que muchas veces se complican emular en el ambiente de prueba. Los ambientes de pruebas se desarrollan en base a resultados esperados en base a los requerimientos diseñados, no obstante, esos resultados esperados no cubren todos los escenarios de lugar  que necesitamos en nuestras aplicaciones para que se encuentren libre de errores.