Uno de los problemas más comunes es que la parte de prueba de la automatización de pruebas es bastante sencilla de automatizar, especialmente con la gran cantidad de herramientas de automatización actuales. Pero saltar directamente a las pruebas automatizadas te deja con un gran montón de scripts de automatización, y a menudo no es el mejor ROI. Comprender por qué requiere examinar el proceso de automatización.

Cuando un ingeniero crea una prueba automatizada, lo hace en un entorno de prueba que ellos (o alguien de la organización) configuraron. Por lo general, esta es la misma forma en que los probadores manuales obtienen acceso a los entornos de prueba.

Antes de que los ingenieros comiencen a automatizar, tienen una copia de trabajo del producto que están probando, con datos relevantes. Tienen una buena idea de la prueba que quieren escribir. Todo parece prometedor.

Escriben la prueba y le dan algunas carreras. Todo se ve bien y estable. Ahora, para proporcionar el ROI que esperábamos, la prueba debe ejecutarse un millón de veces. O, al menos, unos miles de veces, ¿verdad?

Para obtener los beneficios de la automatización, debe suceder con la frecuencia suficiente. Sin embargo, el cuello de botella a menudo se descubre después de crear un montón de pruebas. Debido a que las pruebas deben ejecutarse en un entorno de prueba similar al utilizado para crearlas, con las nuevas versiones del producto o con cualquier cambio introducido que se esté probando, necesita acceso a cientos de entornos. Este requisito hace que sea difícil realizar pruebas de manera efectiva.

A continuación se presentan tres enfoques de entorno de prueba que inhiben la automatización de la prueba.

Configuración manual de un entorno cada vez para ejecutar pruebas automatizadas

Para las pruebas que no necesitan ejecutarse con tanta frecuencia, como las pruebas de seguridad y las pruebas de rendimiento, es común configurar un entorno para pruebas automatizadas cada vez que se necesita ejecutar la prueba. Como resultado, los probadores deben esperar a que el entorno esté listo, tal vez hacer algunas configuraciones adicionales y luego ejecutar un conjunto de pruebas. Y, si intentan optimizar la utilización, se deja que el entorno funcione durante la noche o el fin de semana.

El problema con este enfoque es que elimina el “auto” de las pruebas automatizadas. Cuando la automatización depende de un paso manual, la prueba es tan eficiente como este paso manual.

Si el paso manual no es muy eficiente, la automatización puede no estar ayudando en absoluto. He visto empresas que tardan tanto en lograr un entorno para trabajar que ejecutar pruebas automatizadas en él no haya hecho ninguna diferencia desde una perspectiva temporal.

Configuración de un entorno estático en el que la automatización siempre se ejecuta

Cuando la configuración de un entorno lleva mucho tiempo, es natural suponer que vale la pena dejar un entorno en funcionamiento para que la automatización de pruebas pueda ejecutarse en él. Se hicieron los preparativos, la infraestructura está en su lugar, el producto está configurado y los datos están listos, así que comience la fiesta de la automatización.

Si bien los entornos complejos de prueba estática pueden parecer ideales, pero la fiesta no dura mucho. En primer lugar, dado que generalmente lleva un tiempo armar el entorno (igual que en el caso anterior), a menudo se vuelve de alto mantenimiento. Puede ser aterrador hacer cambios que puedan arruinar las cosas, y puede terminar necesitando a alguien para administrar el cambio a tiempo completo. Al igual que el pastel de chocolate en la cocina de la oficina, un entorno que imita la producción con buenos datos tiende a atraer a todos. Pronto, estos entornos agradables se convierten en activos compartidos y las pruebas comienzan a entrar en conflicto con los mismos recursos. El siguiente paso natural es configurar otro entorno estático. Este ciclo generalmente termina con un gerente enojado que dice algo sobre cortar CAPEX.

Automatizando el medio ambiente y reduciéndonos un poco

Con el auge de la infraestructura como código (IaC) e infraestructura inmutable, hay más formas de activar un entorno de prueba. Los equipos de prueba ingeniosos intentarán automatizar la creación del entorno o utilizar la herramienta de prueba incorporada o las capacidades del sistema CI para ejecutar pruebas en una instancia de nube pública o un contenedor, si el producto que prueban lo permite. Esto es barato y útil, y podría funcionar para algunas pruebas simples. El desafío generalmente comienza con todo lo que este enfoque no cubre. Puede ser difícil usar IaC para activar un entorno de prueba y manejar todos los aspectos del mismo, desde la seguridad y el aislamiento hasta las dependencias, los datos, la integración de terceros y más. Aquí es donde este enfoque a menudo se bloquea y nos devuelve a los dos enfoques anteriores para una gran parte de la carga de prueba, lo que nuevamente hace que la inversión en automatización de pruebas sea menos fructífera.

La forma correcta de configurar entornos de prueba: Automatización de pruebas en entornos dinámicos

El mundo de la automatización de pruebas necesita un cambio de juego. Puede hacer que su automóvil sea más rápido, pero si el camino está lleno de baches, no podrá llegar tan rápido ni tan lejos. La automatización de pruebas está igualmente limitada por el ritmo de creación del entorno, con su infraestructura, aplicación, datos y todo.

Este desafío se vuelve crítico cuando se adoptan DevOps y las pruebas dejan de ser una etapa en la tubería, en lugar de convertirse en un servicio de tubería general. El control de calidad ya no se trata de ser la puerta entre el desarrollo y las operaciones. Se trata de supervisar la calidad del producto durante todo su ciclo de vida. Esto significa que las pruebas automatizadas siempre deben poder ejecutarse, y el entorno en el que se ejecutan debe ser dinámico.

La solución a este desafío son los entornos como servicio (EaaS). EaaS se trata de empaquetar el entorno, incluida la aplicación, la infraestructura y los datos, como una entidad que se puede proporcionar como un servicio a un proceso comercial. Una vez definido, se puede proporcionar a pedido para usuarios manuales o automatizados. Como es una entidad bien definida, también se puede retirar cuando el proceso termina de usarla. Al desempeñar un papel importante en hacer que la infraestructura sea horizontal, EaaS es también la clave para allanar el camino para una automatización de pruebas brillante.

Si cree que debería obtener más de su iniciativa de automatización de pruebas, puede ser un buen momento para hacer que EaaS sea parte de su estrategia de automatización.

Maya Ber Lerner (2019) ¿Por qué falla la automatización de pruebas? Recuperado de: http://blog.quali.com/blog/why-your-test-automation-is-failing

Este artículo apareció originalmente en DevOps.com