03. Ambientes e Infraestructura

Probablemente, algo en lo que todos pueden estar de acuerdo es que hay al menos tres ambientes diferentes para trabajar: uno para desarrollo, donde el código se compila y prueba localmente en cada modificación, uno para que los testers prueben las versiones "cerradas" que están listas para testear, y el entorno de producción, donde se encuentra el código del sistema expuesto a los usuarios.

Nadie considera pasar directamente del ambiente de desarrollo al ambiente de producción, ¿verdad? Eso sería una locura…

Desafortunadamente, algunos equipos hacen precisamente eso, ejecutar pruebas en el ambiente equivocado. Hay muchos que no cuentan ni siquiera con los tres ambientes básicos para realizar estas prácticas, lo que trae muchas consecuencias. En este punto es común escuchar la excusa de los desarrolladores, "bueno, funciona en mi computadora", cuando algo no funciona para el usuario (lo que realmente importa).

Para probar realmente el software antes de que llegue al usuario, es fundamental tener un ambiente específico para este, y a veces, incluso no es suficiente. Especialmente para las validaciones automatizadas, es importante ejecutar estas pruebas con los datos de forma aislada.

Además, es recomendable tener un ambiente separado para asegurar que no se modificarán (si se modifican, existe el riesgo de obtener falsos positivos).

Es fundamental gestionar de forma adecuada el ambiente de prueba, teniendo en cuenta sus múltiples y diferentes elementos:

• Los archivos fuente y ejecutables de la aplicación.
• Los dispositivos de prueba y los datos que usan.
• A su vez, los datos están relacionados con el sistema de base de datos de cada ambiente, por lo que es necesario gestionar el esquema y los datos desde la correspondiente base de datos.

Si hay que realizar varias pruebas con diferentes configuraciones, parametrizaciones, etc., se necesitará más de un ambiente de prueba, o un ambiente y muchas copias de seguridad de la base de datos, una para cada conjunto de pruebas. Esto implica realizar un mantenimiento específico para cada respaldo (por ejemplo, siempre que haya cambios en el sistema en el que se modifica la base de datos, se debe impactar cada copia con estos cambios).

Pero si uno de estos elementos no es consistente con el resto, las pruebas probablemente fallarán y serán ineficientes. Es crucial asegurarse de que cada vez que una prueba detecte un incidente, sea porque realmente hay un error en vez de una falsa alarma.

Para resolver todos estos problemas a nivel del ambiente, usualmente existen roles específicos dentro de un equipo. Una tendencia de la industria muy popular es incorporar DevOps. Hay una pequeña controversia sobre este término, porque el concepto original estaba relacionado con la cultura de equipo y no con roles individuales. Pero, hoy es común que las empresas contraten a un "Ingeniero DevOps". Según Puppet Labs, los equipos que emplean DevOps lanzan versiones con una frecuencia 30 veces mayor, tienen 60 veces menos fallas y se recuperan 160 veces más rápido.

Básicamente, el rol de DevOps es combinar la visión de gestión de operaciones (infraestructura y ambiente), desarrollo y negocios. La conexión de estas áreas permite resolver de manera rápida y eficiente todas las necesidades del equipo, poniendo el foco en el cliente y el usuario final.

En cuanto a herramientas, DevOps suele aprovechar las facilidades de las máquinas virtuales así como otras más avanzadas como Docker y Kubernetes. Cuando se trata de la variedad de dispositivos móviles necesarios para las pruebas, existen varias soluciones para evitar adquirir y mantener diversos dispositivos mensualmente, desde laboratorios de dispositivos hasta soluciones colaborativas en la nube que ofrecen el acceso a múltiples dispositivos mediante una membresía.

Por lo tanto, tener varios ambientes gestionados correctamente ayuda a evitar preguntas como por ejemplo: "¿Estamos seguros de que estamos probando la última versión?". También es fundamental disponer de todos los ambientes que necesitan los testers, esto puede implicar dar acceso a diferentes sistemas operativos con diferentes configuraciones, versiones de navegador o incluso tener acceso a varios dispositivos móviles. Debido a la gran variedad de dispositivos en el mercado y la división dentro de Android y hoy en día incluso con iOS, es necesario probar en la mayor cantidad posible de los dispositivos más relevantes.

En cuanto a la cobertura de dispositivos móviles, una estrategia con la que en Abstracta hemos tenido excelentes resultados es la "cobertura cruzada a largo plazo". Mientras que el testing móvil requiere más tiempo de ejecución, la estrategia de cobertura de prueba cruzada tiene como objetivo mejorar la cobertura a largo plazo.

Esta estrategia propone organizar las ejecuciones de tal manera que no se realicen todas en cada ciclo, sino que se alternen, mejorando la cobertura después de muchos ciclos. Las siguientes imágenes ejemplifican esta estrategia:

Con lo cual, en el tercer ciclo de ejecución se alcanza la cobertura total:

Esto no garantiza una cobertura del 100% en cada ejecución, pero al lograr alternarlas, se logra sucesivamente una mayor cobertura.

Esta misma estrategia se aplica a los navegadores web, parámetros o muchas más variables con las que los testers tienen que "jugar".

Para lograr la madurez de testing de software, se requieren los ambientes necesarios para la ejecución de las pruebas, a fin de garantizar que no haya incidentes adicionales a los que se esperan detectar a través de las pruebas.