Calidad y rapidez: Nuestro viaje de siete años hacia el 99,999% de disponibilidad

Frente a un ecosistema de software muy dinámico, el mundo de las pruebas de software se ha quedado estancado. A medida que los productos crecen en complejidad, los equipos de desarrollo se enfrentan a un dilema: la demanda de entregas rápidas está en guerra con la necesidad de garantizar productos de calidad.

¿Cómo pueden sus equipos adoptar un enfoque más sólido de las pruebas de software sin comprometer la velocidad y el crecimiento del producto?

El creciente equipo SDET (desarrollador de software en pruebas) de I+D de Vonage definió una solución. La llamamos Calidad y velocidadel enfoque de pruebas por capas que aborda tanto la calidad como la velocidad.

¿Dónde empezó?

La mayoría de las empresas centran sus esfuerzos de pruebas en dos áreas principales: las pruebas funcionales, que emulan el uso básico de una aplicación, y la carga no funcional del sistema. Los grupos de pruebas suelen medir la calidad del producto en función de la cobertura de los requisitos y del número de errores encontrados, resueltos o reabiertos, lo que supone glorificar los errores en lugar de prevenirlos.

Pero el mundo ha cambiado. Nos enfrentamos a un aumento de la fragmentación en aspectos como los sistemas operativos, los dispositivos y la latencia de la red. Estamos muy adentrados en la era de las aplicaciones, una era dinámica y altamente competitiva. Estamos viendo APIs y librerías comunes que ahora permiten un desarrollo más rápido, así como diversos servicios en la nube que proporcionan al desarrollador un entorno que no depende de sistemas operativos, seguridad, redundancia o incluso escalabilidad. Todo esto viene a decir que las empresas con ciclos de lanzamiento en cascada de un mes de duración ya no pueden competir con la demanda de funciones e innovación.
Las empresas que no sean capaces de suministrar con rapidez llegarán tarde al mercado.

Las capas

Y, sin embargo, a pesar de la necesidad de velocidad, existe un riesgo en precipitarse a la producción con sólo unos pocos métodos de pruebas de calidad anticuados en nuestro haber. Porque si seguimos haciendo las cosas como llevamos años haciéndolas, acabaremos persiguiéndonos el rabo en un círculo de problemas de calidad y escaladas en producción, lo cual no es divertido para nadie. Nos quedan estos dos factores críticos: La calidad debe mejorar, pero necesitamos la capacidad de introducir cambios en la producción de forma coherente y consciente.

Hace siete años, empezamos a investigar métodos adicionales para añadir a las dos capas originales, las pruebas funcionales y de carga. Durante ese tiempo, hemos construido de forma constante el enfoque de calidad y velocidad que nos llevó al 99,999% de disponibilidad del sistema, conocido coloquialmente como los "cinco nueves."

A través de la investigación y la experimentación, creamos el proceso que aquí presentamos, compuesto por tres capas multidimensionales:

Disciplina de codificación

Puede parecer obvio que una disciplina de código adecuada es el núcleo de la calidad del software. Las pruebas empiezan aquí, en el seguimiento coherente de normas y procedimientos.

• Las revisiones de código deben ser realizadas por iguales, siempre, y el código automatizado debe tratarse del mismo modo.

• Las pruebas unitarias con una amplia cobertura nos permiten probar fácilmente con confianza que no hemos roto el código base.

• Herramientas de análisis estático descubren errores estáticos y vulnerabilidades de seguridad. Hay muchas en el mercado que ofrecen diferentes especificaciones para diferentes necesidades.

• Las pruebas funcionales deben centrarse en la simulación. Pruebe a nivel de API y rodee su automatización con mocks que prueben exactamente lo que ha pedido. Evite las pruebas automatizadas de extremo a extremo porque está probando su código y no el producto de extremo a extremo. Como resultado, la cobertura aumentará y las pruebas serán más estables.

Asegúrese de que las pruebas funcionales se ejecutan en todas partesno sólo en entornos de desarrollo y control de calidad, sino también en producción. Si se construyen correctamente, serán una gran herramienta de supervisión y no fallarán a menudo. Todos sabemos lo frustrante que es recibir una alerta a las 2 de la mañana por una falsa alarma.

Pruebas no funcionales

Para ello, tendrás que salir de tu zona de confort y pensar en grande. Tendrás que conocer el uso medio de tu producto y llevarlo al límite.

Considere una API que sabe que recibe 1.000 llamadas por segundo de media, con un pico de 1.200 a las 10 de la mañana y a las 3 de la tarde, y un mínimo de 800 a las 10 de la noche.

• Para Pruebas de carga querrás hacer 1000 llamadas cada segundo durante unas horas.

• En Pruebas de estrés seguirás añadiendo llamadas hasta que llegues a un fallo. Ese es tu punto de estrés. Decide qué hacer al respecto y vuelve a intentarlo.

• Pruebas de estabilidad Account for average usage over time. Durante un periodo prolongado, realice 1200 llamadas por segundo en horas punta, 800 en horas bajas y 1000 el resto del tiempo. Esto garantizará que pueda mantenerse estable bajo su carga media.

Si su software incluye funciones de autoescaladoasegúrese de realizar pruebas en instancias adicionales una vez alcanzado el límite. Pruebe redundancia para regiones y zonas porque, recuerde, sus servicios en la nube en la nube fallarán de vez en cuando. Seguridad en este contexto se refiere a las pruebas de penetración de aplicaciones, las pruebas de OSS (bibliotecas externas y API) y las herramientas de análisis estático. Las revisiones del código son cruciales en esta fase, y deberían formar parte del ciclo de vida de desarrollo del software.

Disciplina DevOps

Déjalo remojar. No te engañes creyendo que te has protegido de todos los casos extremos una vez que todo lo mencionado anteriormente funcione bien. No es posible. Tienes más dispositivos, más funciones de Account y más configuraciones que considerar. Tómate tu tiempo para asegurarte de que las pruebas son realmente precisas.

Recuerde ser gradual con los lanzamientos

• Fomentar eliminación de errores por parte del equipo de desarrollo antes de pasar a la fase de montaje

• A continuación, inténtelo en el alfa (interno) antes de compartirlo con los usuarios beta (externos). Estos grupos beta seleccionados deben representar a la mayoría de su base de producción, en lo que respecta a instancias y dispositivos.

• Una vez que la versión esté ampliamente disponible, habilite un azul-verde que alterna servidores de producción y de ensayo y permite volver rápidamente a una versión anterior en caso necesario.

• Supervise escrupulosamente; vigile la salud de su sistema, configure alertas y analice los datos de las pruebas.

• Hable con sus equipos de atención al cliente y explore otras fuentes de información, como las tiendas de aplicaciones, las redes sociales y las plataformas comunitarias.

Si ha seguido todos estos pasos, podemos garantizarle que ya está listo para GA.

En conclusión

Lo que acabamos de presentar es un enfoque para una estrategia de calidad que nos parece cercano a la perfección, pero aún alcanzable. Aunque no lo hemos implementado por completo para todos nuestros servicios, específicamente el código heredado y el software heredado, podemos decir con confianza que cada capa ha demostrado marcar una diferencia significativa. El equipo de ingenieros SDET y DevOps de Vonage puede dar fe de ello. Es una empresa enorme, pero te animamos a que añadas gradualmente una capa cada vez, hasta que alcances la cobertura adecuada para ti.

Esperamos que esto le haya ayudado y que esta investigación le acerque aún más a la disponibilidad deseada.