A menudo, el equipo de QA utiliza el entorno de staging como ambiente de pruebas. Sin embargo, esto puede no ser la mejor práctica.

Conversando con diferentes colegas del mundo tech (CTOs, Heads, developers, etc) sobre sus procesos de prueba es bastante común escuchar un “Si tenemos ambiente de pruebas” y después de indagar un poco más resulta que lo que tienen es un stagin y lo tratan como un ambiente de pruebas y cuando mencionó que ese no es un ambiente de pruebas persé no tienen ni idea de las veces que me ha tocado explicar porque no lo es, han sido tantas que incluso llegue a cuestionarme si yo estaba mal, es decir, ¿Qué tal si staging en realidad si es un ambiente de pruebas?, ¿Qué tal si yo soy la que no sabe trabajar con ese ambiente?, ¿Qué tal si alguien más descubrió el hilo negro de los ambientes en testing y yo aún no lo hago?… Pero después de darle muchas vueltas y especialmente basado en mi experiencia profesional, yo no creo que este mal mi pensamiento y tengo 3 razones para sustentarlo.

1. Confiabilidad en las pruebas.

¿Te ha tocado escuchar el famoso “prueba de nuevo, ya se corrigió” (como si fuera arte de magia)?. Bueno, piensa que tienes a un equipo de calidad dedicando tiempo y esfuerzo reportando defectos que no eran defectos por servicios caídos, ramas mal mezcladas, ramas incorrectas o incluso código que no tenía porque llegar a ese ambiente, puede ser la razón mas tonta (y común) de tirar dinero (si dinero) por que al final tienes a todo un equipo de calidad (que no suelen ser baratos) revisando cosas que no tenían porque revisarse y la credibilidad del equipo se va perdiendo, porque son más los falsos negativos que se reportaron que defectos reales.

2. Demostraciones con stakeholders asegurando su éxito.

Imagina que tienes que hacer una presentación a un importante cliente sobre una funcionalidad nueva que aún no esta en producción, llegas a la reunión, comienzas a demostrar cuanto tiempo y dinero puede ahorrar si decide comprar tu producto y de repente tienes una pantalla en blanco. Seguramente tu cliente va a perder el interés en el producto, la experiencia puede ser tan mala que deciden no asociarse contigo y todo porque el equipo de tecnología decidió integrar algún cambio relacionado que hizo que el ambiente dejara de funcionar.

3. Autonomía al equipo de calidad.

Existen actividades hormigas que terminan robándonos bastante de nuestro tiempo, si los compactáramos todas juntos, por ejemplo: el hecho de que te sientes a ver videos de TikTok por 15 min cada 2 horas inicialmente te da una sensación de no invertirle mucho tiempo, pero si te pones a ver la pantalla completa, estas dedicando casi 1 hora por cada 4 horas “productivas”… Entonces, ¿prefieres tener a tu equipo de desarrollo mezclando ramas en un ambiente para que otro equipo lo pruebe, entendiendo que implica que dejen de lado sus actividades primordiales (codificar, revisión de código, couching, etc) o prefieres que el mismo equipo de calidad suba y baje cambios en su ambiente para ir testeando conforme se vaya requiriendo?

Sí llegaste a este punto y decidiste tener un ambiente de pruebas real, ¡muchas felicidades! en nombre de todos los QAs del mundo te doy las gracias por encaminarte hacia el lado de las buenas prácticas de testing… pero entonces, si ya tienes un ambiente exclusivo de pruebas, ¿que vas a hacer con stage?

La respuesta es muy fácil, úsalo como ambiente de validación previa al release, te explico un poco:

Si tu eres ingeniero de calidad.

• Seguramente ejecutas pruebas de regresión, estas pruebas de regresión deben de hacerse en el ambiente de staging, una vez que tu feature esta lo suficientemente estable y las pruebas funcionales pasaron, es momento de ir al siguiente nivel.
• ¿Has escuchado o practicado las pruebas UAT? (personalmente no creo que sea responsabilidad del equipo de calidad, sin embargo eso es tema para otro post), bueno para este tipo de pruebas utilizaremos este ambiente ya que como sabes las pruebas UAT deben de hacerse en un ambiente 100% estable y lo más parecido a producción, esto asegura que tu usuario obtenga la sensación lo más real posible sin data mockeada o servicios emulados.
• Utilízalo para las pruebas de estrés, performance, carga, seguridad, etc, que normalmente no se pueden llevar acabo en los ambientes de prueba debido a sus limitados recursos (esto pensando que no existe un estrategia de calidad que contemple un ambiente exclusivo para pruebas de performance, por ejemplo, pues sabemos que este tipo de ambientes necesita ser especialmente controlado).

Si tu eres parte del equipo de tecnología (dev, devops, sre, etc)

• Necesitas mantener el ambiente lo más estable y parecido a producción (hablando meramente de recursos, servicios, memoria, base de datos, banderas o alguna configuración especifica, etc)

Si tu eres parte de cualquier otro equipo:

• Utilízalo para demostrar nuevas y viejas funcionalidades a tus futuros clientes, pero esta vez hazlo con la seguridad de que nada se va a romper.
• Dale un vistazo y reporta todo lo que encuentres “raro”, recuerda que la calidad la hace todo el equipo por lo que cualquier observación que tengas (por más chiquita que sea) será bienvenida.

En cambio, si llegaste hasta acá y aún así decides que no necesitas un ambiente de pruebas solamente espero que tus argumentos no sean como estos:

En conclusión…

Aunque el entorno de stagin es un ambiente atractivo y común para realizar pruebas, no es adecuado para el equipo de calidad. El equipo de calidad debe utilizar un ambiente de pruebas dedicado que esté diseñado específicamente para realizar pruebas exhaustivas. Esto ayudará a garantizar la calidad del software y evitará problemas en la etapa de implementación además de que el ambiente de pruebas no solamente te brinda procesos más limpios si no también métricas más exactas.

Recuerda que siempre y cuando toda el área/empresa este en la misma linea se pueden hacer grandes cosas, compara el antes y el después de implementar un ambiente de pruebas, es decir, contabiliza el tiempo de pruebas, el numero de defectos reales, la calidad de pruebas, etc.

Creo que de este post podemos sacar muchos otros como, el gitflow ideal cuando tenemos un ambiente de pruebas. Y tu ingeniero de calidad, que al igual que yo te sentiste fuera de lugar por pensar que quizá un ambiente de pruebas no era necesario, créeme es vital para que el equipo brinde la mejor calidad en sus actividades. Muéstrale este post a tu manager, head, lead, a esas personas que no están seguras de cubrir esta necesidad y encaminence al trabajo de las buenas prácticas.