¿Esta prueba es candidata a la automatización? Es una pregunta que nos hacemos frecuentemente en los equipos de Testing. En general la automatización es una buena práctica. Pero hay casos en los que nos sale más rentable hacerlo de forma manual. Sigue leyendo y te explicaré el por qué.
Índice de contenidos
¿Cómo saber si una prueba es candidata a la automatización?
Lo primero que tenemos que tener en cuenta es el escenario. ¿Nos encontramos en un proyecto que ya está en desarrollo?, ¿o vamos a comenzar la creación de un nuevo producto? ó ¿ese proyecto está ya en mantenimiento? En función de cada una de las opciones tenemos que evaluar unos puntos u otros. No se debe medir solo por el beneficio o coste que supone. No tenemos el mismo nivel de conocimiento sobre las pruebas en cada caso, así que tendremos que contemplar puntos distintos en función del escenario.
Proyecto en desarrollo
Para saber si una prueba es candidata a la automatización en el proyecto que estamos desarrollando tenemos que analizar una serie de puntos, aunque que también partamos de los puntos anteriores
Frecuencia de la utilización de ese componente
Se debe evaluar la frecuencia con la que es utilizada esa funcionalidad. A veces, la verificación de ese módulo del sistema se ha realizado en las primeras fases, de forma manual. Ya ha sido validada y verificada de forma sencilla y no es necesario repetir esa comprobación de forma automática.
Tiempo del que disponemos
Automatizar una prueba requiere un tiempo elevado de tiempo. Como mínimo necesitamos el doble de la ejecución de forma manual. Sí estamos en una fase en la que queda poco para la entrega del mismo, no es muy recomendable esta opción. Tendríamos el caso contrario si implementamos testing temprano, con metodologías más ágiles. en este último caso podríamos planificar la automatización.
Perfil del usuario que realizará la prueba
Los casos de pruebas son ejecutados por un gran número de usuarios. Participan desarrolladores, testers, miembros del equipo de nuestro cliente y hasta en ocasiones usuarios reales. En función de quién ejecutará la prueba tiene más sentido o no su automatización. Para los miembros de nuestra empresa es interesante que un conjunto de pruebas sean automatizadas. Sin embargo, el usuario final realiza las pruebas de forma manual.
Estabilidad de las versiones
En función del punto en el que nos encontramos, y las posibilidades de cambios importantes en el proyecto es frecuente descartar la automatización. A la hora de evaluar si una prueba es candidata a la automatización debemos tener en cuenta, que puede quedar obsoleta rápidamente.
Herramientas para la automatización
Una prueba es candidata a la automatización en función de la tecnología que se ha utilizado en el desarrollo y las herramientas de las que disponemos. No siempre soporta esa tecnología. Cuando no se ha planificado previamente, nos podemos encontrar con esa dificultad.
Complejidad de la funcionalidad
A veces nos encontramos con casuísticas complejas, que al ser ejecutadas de forma manual pueden provocar errores humanos. En este caso, es recomendable la automatización sin lugar a dudas.
Criticidad y relevancia
En un escenario normal, no contamos con tiempo infinito. Por ello es importante evaluar y revisar cuáles son los casos de pruebas que verifican los requisitos más críticos e importantes. De esta forma nos aseguramos que lo que aporta más valor al proyecto es correcto, y podemos revisar de forma manual el resto de necesidades con menos relevancia.
Nuevo producto a desarrollar
En este caso tenemos muchas opciones a evaluar. Lo principal es realizar un buen análisis del producto a desarrollar, utilizar herramientas que nos permitan registrar toda la información. De esta forma tendremos un buen acceso para rectificarlas, actualizarlas o consultarlas. La información la tendremos disponible para ser evaluada en cada momento. Sabremos que requisitos fallan y que es necesario probar de forma repetitiva. Si además, contamos con un sistema que nos permite ejecutar los mismos script en distintos escenarios tenemos los mejores recursos para la toma de decisiones.
Lo importante es comenzar desde el principio con las tareas de testing, participando en todo el ciclo de desarrollo del producto para contar con el máximo de información y, si es posible, participar en la toma de decisiones. Por supuesto, tendremos en cuenta los puntos mencionados en el apartado anterior.
Proyecto en fase de mantenimiento
En este tipo de proyecto se suele contar con un plan de pruebas, bien de su fase de pase a producción o de necesaria necesidad por correctivos posteriores. Pero en todo caso, no siempre se cuenta con un plan de pruebas automatizado. Por ello, además de los puntos anteriores, se deberá tener en cuenta
Historial de incidencias
¿Qué fallas o errores ha tenido desde su publicación? Este listado de puntos, y el conjunto de las pruebas ejecutadas en la implantación del correctivo de cada caso, son una gran fuente de información para seleccionar que prueba es candidata a la automatización.
Plan de continuidad
Es frecuente de disponer de un plan de pruebas críticas que se ejecutan cuando se realizan actualizaciones programadas del sistema. En este caso, disponemos de un conjunto de pruebas, que no suelen quedar obsoletas y que se ejecutaran con cierta periodicidad. Aquí nos encontramos con un escenario en el que es muy recomendable la automatización.
Referencias:
Conclusiones: Es necesario evaluar si una prueba es candidata a la automatización antes de proceder
Son muchos los puntos a tener en cuenta para decidir si una prueba es candidata a la automatización o no. Por ello es importante que nos rodeemos en todo momentos de herramientas que nos ayuden a gestionar esa gran cantidad de datos y así, nos facilite la toma de decisiones. Si realizamos una automatización no recomendada, podemos incurrir en un gasto de tiempo precioso para asegurar la calidad del producto.
Si te ha gustado este post, déjame un comentario o suscríbete al blog para estar al día de los nuevos contenidos que llegaran