Automatización de pruebas de software: por qué y cómo

06/09/2021

Es crucial responder a varias preguntas antes de iniciar el viaje de la automatización de pruebas de software. En este artículo, también te ayudamos a que analices tú mismo algunas de las más importantes.

Un grupo de colegas debate sobre la automatización de las pruebas de software

La carrera por la automatización de las pruebas de software tiene el potencial de no cumplir las expectativas del cliente, un número incontable de scripts "basura" que nadie utilizará, debido a un simple cambio funcional o en la arquitectura del sistema. Y, una larga espera para el prometido retorno de la inversión y el ahorro esperado.

Todo ello por no establecer claramente la dirección y los objetivos de las iniciativas de automatización de pruebas de software desde el principio del viaje.

Un camino claro empieza por el porqué

Para evitar estos resultados no deseados, es crucial responder a varias preguntas antes de iniciar el viaje de la automatización. En este artículo, te ayudaremos a analizar tú mismo algunas de las más importantes:

¿Por qué automatizar las pruebas de software?

Esta pregunta puede parecer obvia, y muchas organizaciones pueden tener ya varias respuestas claras en mente. "Para ahorrar horas en las pruebas de regresión", "para promover la agilidad", o "para controlar los entornos pre-productivos", por nombrar algunos. En cualquier caso, por qué la automatización de pruebas de software, sigue siendo la pregunta más importante.

Y tan clave como definir el porqué, es igualmente crucial comunicarlo a su equipo para que nadie pierda de vista los objetivos de automatización.

En un caso, aunque los objetivos de automatización estaban claros y se habían compartido con el socio, éste tomó un camino diferente y creó un gran número de secuencias de comandos sobre el mismo flujo de trabajo.

Con tantos guiones, resultaba muy difícil gestionarlos y controlarlos. Entonces el software cambió. Se hizo imposible mantener todos los scripts, así que fue más conveniente volver a desarrollarlo todo desde cero. Pero esta vez, haciendo todas las validaciones del flujo en un único script.

Los muchos cómos de la automatización

Una vez claro el objetivo de la automatización, otra pregunta importante es: "¿cómo hacerlo?". Y de ella surgen otras varias, como:

¿Qué sabemos sobre la automatización?
Lo primero que recomendaría es identificar el AS-IS en términos de lo que sabemos sobre el tema. La brecha entre el AS-IS y el TO-BE es una de las primeras cosas que hay que eliminar o reducir. Todo lo que hagamos debe basarse en un conocimiento sólido del tema. Contar internamente con personas cualificadas o con un socio experimentado puede ser muy útil en esta fase.

¿Tengo un equipo o un socio con los conocimientos necesarios?
Contar con las personas adecuadas, o con un socio, es clave para el éxito. No sólo por los conocimientos técnicos, sino también por la capacitación que asumen de cara al objetivo.

¿Cuánto costará el proyecto?
Normalmente, una PdC (prueba de concepto) o un MVP (producto mínimo viable) bastan para hacernos una idea de los costes. Aunque la mayoría de las PdC siguen siendo productivas, la forma en que se consiguen no debe convertirse en absoluto en el proceso para el futuro. Una PdC tiene como objetivo saber si "se puede hacer", y si es así, ¡es hora de empezar a planificar!

¿Cuándo debo esperar ver resultados?
Al fin y al cabo, la automatización es un proyecto de desarrollo, por lo que su planificación es sencilla. O puede abordarse dentro de un sprint, por lo que los tiempos vendrán determinados por el tamaño de lo que queramos hacer. El escenario ideal es: tomar un sistema que sea un buen candidato para la automatización, automatizar un flujo de complejidad media y, a continuación, utilizar este tiempo de referencia para planificar el resto de los flujos del sistema.

¿Debo automatizarlo todo?
No necesariamente: calidad antes que cantidad. Técnicamente, me atrevería a decir que "el 100% de las pruebas pueden automatizarse". Sin embargo, para conseguirlo, incurriríamos en costes muy elevados, lo que nos obligaría a descartar la idea.

¿Qué es realmente conveniente automatizar?
Priorizar lo urgente sobre lo importante es una buena técnica, o el ya viciado 80/20 (Pareto). Al fin y al cabo, lo importante es tener muy claro el valor que aporta el script que estoy desarrollando al cumplimiento de los objetivos de negocio.

¿Cómo mediré el resultado de mi automatización?
Establecer KPIs. Como en cualquier planificación estratégica, los KPI deben establecerse en función de la meta principal y los objetivos secundarios. Considera algunos indicadores de calidad, que también son relevantes en este ámbito. Algunos ejemplos de KPI son:
- Tasa de defectos: defectos encontrados por el script (idealmente utilizando la densidad de defectos).
- Tipos de defectos: codificación, entorno, datos, etc.
- Tasa de fallos: a partir del 100% de la ejecución de un script, qué porcentaje resulta en error.
- Minutos de ejecución manual VS minutos de ejecución automatizada: permite identificar el ahorro de tiempo generado por tu script.
- % Cobertura de Automatización: flujos automatizables sobre el universo total de flujos de prueba del sistema (no es recomendable definir un objetivo alto. De hecho, ni siquiera deberíamos tener un objetivo).
- % Progreso en el desarrollo de la automatización: flujos automatizados VS flujos automatizables. En función de su plan, debe comparar lo previsto con lo realizado.

Lección clave: planificación automatización de pruebas de software

Así que, hasta aquí, entendemos que automatizar no es tan trivial como nos dijeron: montar un servidor cualquiera (normalmente cualquier estación de trabajo), generar un script con cualquier herramienta, y dedicarnos a ejecutar una y otra vez como si cuantas más ejecuciones o script tengamos, más cerca estaremos de nuestro objetivo. Simplemente no funciona así.

Lo que debe quedar después de este análisis es que antes de emprender el camino de la automatización, hay que detenerse, el tiempo que sea necesario, para claramente: definir objetivos > planificar > priorizar > definir KPIs y objetivos > y establecer puntos de control y métodos de seguimiento centrados en el valor de la automatización, no en la cantidad de script que tenemos que desplegar.

Y en el caso de que ya estés en este camino, y el panorama no sea positivo, hazte estas preguntas para orientarte hacia las oportunidades de mejora de tu equipo.

Unas palabras finales sobre la automatización de las pruebas de software

Para terminar, y volviendo al "por qué", a continuación se presentan algunos enfoques que se pueden dar a la automatización al tiempo que se añade un gran valor a la organización:

Automatizar para promover la agilidad
Bajo esta perspectiva, no es conveniente automatizar el 100% de los casos de prueba. En su lugar, considera sólo los flujos de trabajo funcionales más críticos para evitar cualquier impacto en el negocio debido a una nueva versión (pruebas regresivas). Adicionalmente, también es bueno incluir aquellas pruebas que tarden más en ejecutarse manualmente (para centrarnos en las pruebas manuales de los nuevos casos / flujos que creemos debido al cambio en el código). Por último, incluir las más complejas que requieran conocimientos funcionales avanzados (esto también permite prescindir del analista funcional experto que debe estar centrado en otros flujos). Las ejecuciones de estas pruebas se disparan idealmente en un esquema de integración continua antes del push de una nueva modificación de código y tras la ejecución de la correspondiente inspección de código de datos (idealmente también automatizada).

Automatizar para controlar la estabilidad de los sistemas
Al realizar una modificación importante en un sistema, los análisis de impacto suelen pasar por alto algunas integraciones con otros sistemas y es habitual que un impacto no identificado afecte al funcionamiento de uno o varios sistemas. Esto provoca que las pruebas se detengan hasta la corrección o reversión del cambio. En este enfoque de la automatización, es recomendable considerar sólo los "Happy Paths" y probar estos flujos de trabajo varias veces al día de forma programada (por ejemplo, con Jenkins) permitiéndonos conocer rápidamente a través de un Dashboard online si un sistema, servicio o servidor encuentra problemas. Si vamos más allá en cuanto al aviso "online", podemos activar un correo electrónico, un SMS o un mensaje de alerta en herramientas como HipChat para que los miembros del equipo se enteren rápidamente sin tener que ir a mirar el cuadro de mandos.