Cómo sosegar a los Service Managers: TestOps

Tradicionalmente, la realización de pruebas en entornos de producción se ha visto siempre más como un problema que como una solución. Haciendo testing y buscando errores directamente en entornos de explotación se podían desestabilizar fácilmente los entornos productivos y además corríamos el riesgo de desvirtuar los datos de negocio.

Así que: ¡Prohibidísimo! ¡Anatema tecnológico!
La necesidad obliga:

No obstante, en los últimos años el empuje más vigoroso del agilismo como enfoque para el desarrollo de software y la aparición de capacidades DevOps, han acelerado mucho el proceso de entrega de software a entornos productivos para cubrir las necesidades del negocio y las crecientes exigencias de los usuarios.

Esta situación obviamente ha ido añadiendo más presión sobre los equipos de QA y ha hecho necesario recurrir a mejorar el Shift Left Testing para anticiparnos a los problemas, la automatización de pruebas, el Testing Continuo … antes de que aparezcan directamente en producción.

testop

Pero esto no es suficiente…

Para abordar adecuadamente todos los retos que supone en producción una avalancha de entregas y despliegues, si no continua si muy frecuente, necesitamos poner todavía más energía en el proceso QA .

En este escenario tenemos más probabilidades de tener código inestable en producción y entregas problemáticas que hay que revertir para devolver la estabilidad al sistema. Normalmente los problemas en producción se centran en problemas de configuración, pérdida de rendimiento y deficiente UX.

Y esto pone muy nerviosos a los Service Manager de Explotación y también a los equipos de negocio claro …

¿Cómo podemos resolverlo?

Desde mi experiencia, mi respuesta sería: QAOps, TestOps, Shift Rigth Testing o como queramos llamarle… pero hay que actuar.

Tenemos que tratar de implementar nuevas técnicas de QA que nos ayuden a mitigar esos riesgos, evitando además los problemas de inestabilidad o distorsión de datos que pudieran provocar las pruebas.

Algunas técnicas serían:

1. Monitorización continua de la calidad

Se trata de evaluar la calidad del sistema en cualquier etapa del ciclo de vida del software. La calidad de la aplicación es vigilada utilizando diferentes herramientas y técnicas disponibles en el mercado.

Code instrumentation: Es una técnica usada ya desde hace mucho tiempo, incluyendo en el código fuente de nuestras aplicaciones librerías de monitorización, debug y logging para darnos información cuando se produce un crash en la ejecución. Tendremos logs con trazas que nos “iluminen” para rastrear los errores que se estén produciendo.

Monitorización real: Emplearíamos usuarios reales ( Friends&Family por ejemplo o  servicios de Crodwsource testing) para tener feedback sobre la aplicación respecto a usabilidad,  compatibilidad y experiencia de usuario. Con esta información se irá afinando la aplicación en siguientes releases.

Monitorización sintética: Construiremos pruebas automáticas predefinidas que controlan a modo de sonda la disponibilidad y el rendimiento de determinados flujos de negocio que se puedan considerar críticos para la aplicación.

2. Chaos testing

Hay errores que no somos capaces de encontrar en etapas previas que no sean producción o entornos espejo. Basándonos en Chaos Ing. de Netflix, se trata de introducir de manera intencionada errores o ataques en la infraestructura sobre la que corre nuestro sistema para comprobar la resiliencia del mismo en un entorno controlado, y prepararnos para cuando ocurra en real. Podemos introducir por ejemplo estrés en el almacenamiento, caída de máquinas, retardo de red, sobrecarga de CPUs o varios de estos fallos en cascada para ver como de resistente es nuestra plataforma y cuáles serían las soluciones de emergencia si se da esta situación.

3. A/B Testing

Esta técnica nos sirve para comparar una nueva versión con la anterior y comprobar cual funciona mejor y da mejor funcionalidad, rendimiento, usabilidad etc para que sea la candidata a estar en producción. El testing para comparar versiones se realiza con la combinación de usuarios y el uso de herramientas de monitorización. El surgimiento de cloud, los contenedores dockers, infra as code y kubertenes nos han ayudado bastante a poder implementar A/B testing más fácilmente.

4. Canary Testing

También conocido como “Incremental release testing” es una técnica para distribuir nuevas funcionalidades sólo a un grupo reducido de usuarios de modo que si hay errores en la nueva distribución de software el impacto sea mínimo y se detecten en un entorno controlado. Una vez más se pueden usar Friends&Family (personas cercanas a la organización) para asegurar también la notificación rápida del error sin afectar a la imagen de marca. Una vez más gracias a la ayuda de DevOps esta técnica es más fácil de realizar actualmente.

Por cierto, como algunos sabréis lo del canario viene por el uso en las minas de los canarios como “testers” para detectar gases tóxicos. En este caso no hará falta que ni el software, ni el tester, ni el usuario de negocio se desmaye como el canario cuando aparezcan los bugs tóxicos en los entornos de producción, porque se trata de evitar esta situación.

En resumen:

Aplicando estas técnicas, los equipos enfocados en usar TestOps deberían conseguir que los Service Manager y responsables de negocio se tomen con más tranquilidad los pases a producción y les evitemos ”infartos” por errores graves e inesperados en explotación cuando se despliega una nueva release.