Cuando si y cuando no se debe automatizar

Hoy en día muchas empresas software, por su negocio quieren ser ágiles. Quieren sacar productos
más rápido al mercado y adelantarse a la competencia, mejorando para ello la calidad de su proceso,
producto y equipos software.

Una de las claves para agilizar ese proceso, es la optimización y automatización de ciertos procesos
y pruebas (muy relacionado con Integración Continua).

Automatizar pruebas tiene un costo alto, ya que Integración Continua, testing ágil, automatización
de pruebas tienen aún un valor muy poco accesible.

El objetivo de la automatización de pruebas no es eliminar por completo el testing manual, ni

suplantar a los testers manuales. Lo automatizado son chequeos, comprobaciones que los testers
manuales previamente han detectado antes: ciertas pruebas de regresión, smoke test etc.

Durante la evolución de un sistema, un caso de prueba comienza siendo manual, para luego ser
automatizado. Así los testers manuales pueden dedicarse a buscar otros bugs más complejos o
testear nuevas funcionalidades.
Incluso puede haber ocasiones en las que automatizar alguna prueba o generar las condiciones
necesarias para ello sea tan costoso, que sea más rentable mantenerla manual.

Es cierto que las son automatizaciones necesarias en la interfaz gráfica, pero no son las que más
retorno de inversión aportan, ni las que deberían automatizarse en mayor cantidad.
Principalmente, porque la interfaz de usuario es la parte más propensa a cambios de toda la
aplicación, y para automatizar pruebas y tener fiabilidad sobre lo que estamos ejecutando
necesitamos cierta estabilidad: un cambio en la interfaz podría hacer fallar la prueba automática, y
en ese caso, tendríamos que readaptarla para que volviera a funcionar.
Por eso este tipo de pruebas suelen tener un valor de mantenimiento mayor que el resto.
Sí que tenemos que automatizar las pruebas de interfaz, lo mejor es que se haga después de haber
automatizado otras partes más estables de la aplicación, el núcleo en sí, que aporta más retorno de
inversión.

Por ejemplo, un buen primer paso es automatizar los test de API (funciones, elementos que
ofrecemos desde nuestro software para que otro software, u otras partes del nuestro, puedan
interactuar con él).

Pirámide de Cohn.
La pirámide de pruebas de Mike Cohn, descrita en su libro Succeeding with Agile, ha sido un
referente en este campo durante mucho tiempo.
En ella Cohn establece que hay varios niveles de pruebas, y señala el grado en el que deberíamos
automatizarlas. Lo ideal sería:

– Muchos tests unitarios automáticos, porque un primer punto primordial para detectar fallos es a
nivel de desarrollador. Si una funcionalidad en este punto falla, podrían fallar pruebas de los
siguientes niveles: integración, API etc.

– Bastantes tests a nivel de API, integración de componentes, servicios, que son los más estables y
candidatos a automatizar.

– Menos tests de interfaz gráfica automatizados. Ya que estos tests son variables, lentos en su
ejecución y con muchas dependencias con otros componentes.

– Un nivel estable de pruebas automáticas, que vayan detectando los testers manuales y se vayan
automatizando paulatinamente, para que llegue un momento en el que invirtiendo los mismos
recursos logremos cada vez una cobertura mayor de pruebas.

Mala estrategia de automatización: el patrón del “cono de helado”

En la automatización de pruebas hay que tener cuidado, ya que en ciertas ocasiones se tiende a
perder el foco y a invertir en automatización en el nivel y grado no adecuado.

Una mala estrategia en estos casos, es lo que llamamos el patrón “del cono de helado”.
Como ves es lo contrario a la pirámide de Cohn: centramos el foco en muchas pruebas manuales y
en automatizar pruebas de interfaz de usuario, y nada de pruebas unitarias. Con todos los problemas
que acarrea no detectar errores en los otros niveles y dejarlo todo para la parte más visible de la
aplicación.

Además ten en cuenta, que una buena estrategia de automatización de pruebas conlleva más cosas
que solo automatizar las pruebas en sí: crear un buen framework de automatización, parametrizar
los tests, las ejecuciones para los distintos entornos, lanzar los test con distintos datos de prueba y
gestionar dichos datos, sistemas de logs, buenos reportes con información que sirvan para obtener
conclusiones, montar una buena infraestructura contra la que lanzar esos tests, paralelizarlos etc.

La automatización conviene cuando las pruebas se deben repetir muchas veces. Esto permite
recuperar la inversión realizada en la automatización cada vez que se repite la prueba,
comparándola con haberla hecho en forma manual. Se estima que el retorno en la inversión se
comienza a dar a partir de la tercera o cuarta vez que se repite una prueba, ya que el proceso de
automatizar requiere más trabajo que hacer una prueba manual.
Otro factor que indica la conveniencia de automatizar es si la prueba es muy larga, tediosa o
compleja, lo que permite asegurar que la prueba automatizada se ejecuta consistentemente todas
las veces, ya que las personas tienden a perder la concentración y pueden hacer errores en pruebas
de ese tipo
Tomado de .. https://www.javiergarzas.com/2015/01/automatizacion-pruebas.html