Pruebas Automatizadas vs Automatización de Pruebas
¿Nos enredamos con los conceptos ó dejamos que el entusiasmo nos enrede?
Estaba revisando #30daysoftesting enfocado en automation y el primer reto me hizo recordar una charla recurrente que he tenido con diferentes equipos que se trazan como objetivo “automatizar” y enfocan los esfuerzos en scripts, en construcción de frameworks y luego no saben por qué el esfuerzo no se tradujo en el tan esperado recorte de tiempo en testing total(entre otras promesas).
La razón de ello, en la mayoría de los casos, es que no hay una distinción clara entre el concepto de pruebas automatizadas y automatización de pruebas.
Una prueba automatizada es básicamente un check manual codificado, la definición larga sería algo así como eliminar la intervención humana o manual para el cumplimiento de ciertos pasos que verifican el correcto funcionamiento de un proceso o funcionalidad de un producto software. Para lograr esto tenemos decenas de herramientas a gusto de cada uno y con propósitos diferentes, usualmente para pruebas de UI o visuales emplearemos algo como Selenium y el lenguaje de programación de preferencia, Postman si quieres automatizar llamadas a API ó Jmeter si quieres automatizar algo tan complicado como tests de carga. La razón de ser de una prueba automatizada es repetir los pasos que ejecutaría un humano para verificar cierto output objetivamente, por ejemplo la creación de una cuenta de usuario.
Automatización de pruebas implica automatizar el proceso para ejecutar pruebas, a este nivel ya pensamos en cómo integrarnos a la construcción misma del producto y si nuestra meta es hacer Testing Continuo, el enfoque va hacia integrar la ejecución de pruebas al proceso de Integración/Entrega Continua, a nivel de herramientas…agregar la ejecución de nuestras pruebas al script del CI Server sea Jenkins, CircleCI o el que sea. La necesidad esencial que cubre la automatización de pruebas es el cómo hago para que mi set de pruebas se ejecute autónomamente, sin humano de por medio.
Entonces un equipo puede tener pruebas automatizadas que se ejecutan localmente, a demanda ó, y esto es una meta personal, mediante un comando en slack y no necesariamente haber cumplido con el objetivo de automatización de pruebas, para cumplir éste objetivo es necesario integrarse al ciclo completo de despliegue y es al dar éste gran paso cuando podemos obtener, a opinión personal, 3 grandes beneficios:
- Recortes o ahorro significativo en el tiempo. Imagina que en cada commit que se haga a master se haga despliegue automágicamente a tu ambiente de pruebas, ahora imagina que inmediatamente luego de despliegue se ejecuta tu set de pruebas de regresión mágicamente sin que te des cuenta, a menos que algo falle 😱
- Feedback “instantáneo”, como consecuencia del punto 1 no sólo ahorras el tiempo de pruebas de regresión sino también obtienes un feedback mucho más temprano sobre el estado de tu nuevo despliegue sin incurrir en incidencias que no sólo bloquean la ejecución de pruebas pero también consumen tiempo en encontrarlas y sin intervención manual 🙌
- Proactividad en varios niveles, desde emplear el tiempo no consumido en regresión o pruebas humo para mejorar o establecer una estrategia de alertas o notificaciones sobre las ejecuciones ( y acá siempre voy a considerar slackbots ❤) hasta la creación o dedicación a otro tipo de pruebas que podrían ser de performance, seguridad o inclusive de usabilidad.
Mi mensaje final es que no terminemos la fiesta al ver un repositorio lleno de scripts con pruebas automatizadas, hagamos que esos scripts se ejecuten sin nuestra intervención.
