La importancia del Testing en DevOps

En anteriores posts de nuestro blog, hemos explicado en qué consiste el concepto de DevOps así como las bases para la implementación de una Deployment Pipeline de entrega de valor. En esta ocasión me quiero centrar en un elemento clave que hace posible que todo esto funcione: el testing. Una correcta estrategia de testing es lo que nos da la confianza necesaria para dar el paso para implementar la entrega continua de valor o continuous delivery.

Si analizamos la deployment pipeline que diseñamos en los posts anteriores vemos que siempre, tras cualquier tarea que hagamos, le aplicamos una validación que nos informa de que lo que hemos hecho está correcto. Realmente el concepto clave es feedback. El testing es nuestra herramienta de feedback. Necesitamos saber qué es lo que ha pasado y lo necesitamos rápido. Por tanto, dos características básicas de cualquier estrategia de testing son que:

• Nos proporcionan feedback.
• Son rápidas.

De esta manera, cuanto antes incorporemos el testing a nuestro proceso antes tendremos el feedback deseado. Dentro de la terminología DevOps se suele decir que debemos hacer “Shift Left” al proceso del testing. Es decir, incluirlo al principio del proceso y no al final como suele ser habitual en procesos tradicionales. Además, el testing desde el punto de vista de DevOps es continuo. Es una actividad dentro del trabajo diario, no una fase que se ejecuta tras completar otra fase previa. Éste es uno de los cambios más importantes en la mentalidad del testing respecto al enfoque tradicional, en el que el testing es considerado una fase ejecutada por un equipo de calidad distinto al que desarrolla y tras el fin de la fase de desarrollo.

“El testing es una actividad integrada en el desarrollo, no una fase posterior al desarrollo.“

Una metáfora para entender la importancia de obtener feedback rápido de los errores es, por ejemplo, el corrector ortográfico. A medida que escribimos el corrector nos indica inmediatamente cuándo cometemos un error. Realmente, para cada palabra se aplica el “test unitario” que comprueba si la palabra escrita pertenece a un diccionario. Es decir, nos proporciona feedback de manera muy rápida, siendo el tiempo de corrección de los errores ínfimo.

Imaginemos que, en vez de eso, le pasáramos nuestro documento a un segundo equipo para que lo revise, cuando tenga tiempo, y que nos lo devolviera junto con otro documento distinto, resultado de la revisión, en el que se nos indicará dónde hemos cometido los errores para que los corrijamos ¿Cuánto se tardaría en elaborar un documento libre de faltas? ¿Cuál es el tiempo de ciclo? Por increíble que parezca, ése es el modelo tradicional de testing: tras finalizar un desarrollo entregamos un software y se nos devuelve un documento con la lista de errores encontrados.

Hagamos un experimento mental e imaginemos que, obviando el uso del corrector automático, incluyéramos a la persona que va a revisar el documento en el equipo y que hiciera pair review a la vez que se escribe el documento. ¿Cuál sería el resultado? Sería muy difícil que se incluyera un solo error.

El Testing es una herramienta de colaboración

Otro punto de vista es que el testing es una actividad de alta colaboración entre los distintos miembros del equipo. Es lo que nos permite generar un conocimiento compartido de los problemas de negocio. En este sentido soy bastante fan de BDD (Behavior Driven Development) no como una herramienta que permite la automatización del testing, que también, sino como una herramienta de colaboración y mecanismo de comunicación entre negocio, desarrolladores, QA y todos los implicados en el desarrollo. En combinación con la técnica de los 3 amigos, el testing se convierte en una herramienta muy poderosa para el entendimiento de los problemas a resolver.

Automatización de Testing en DevOps

Un elemento fundamental de DevOps cuando hablamos de testing es que debe automatizarse e incluirse en la Pipeline. Esto nos permite que dicho testing se ejecute sistemáticamente sobre los desarrollos generados, lo que nos genera un feedback continuo y rápido sobre nuestro trabajo. Esta automatización nos sirve también como test de regresión sobre el código antiguo. En este punto vemos cómo el testing proporciona confianza al proceso de despliegue de nuestros desarrollos, confiando en que nos proteja del peligro de introducir problemas indeseados en el entorno de producción.

A la hora de automatizar siempre hay que tener en cuenta el patrón de automatización de la siguiente pirámide:

Este patrón hace hincapié en la cantidad de tests automatizados que hay que implementar dependiendo del nivel en el que nos movamos. De esta manera, nuestros esfuerzos para la automatización del test deben ser a nivel testing unitario y no de GUI (Graphical User Interface o interfaz de usuario) (que suele ser en lo primero que se piensa a la hora de automatizar el testing).

Testing exploratorio

Inevitablemente siempre que se habla de automatizar el testing surge la pregunta de dónde deja esto a las personas como actores de la actividad del testing. Evidentemente los tests automatizados no se hacen solos y alguien tiene que hacerlos. Por tanto, en ese ámbito hay mucho trabajo para las personas. Pero, además de eso, hay un área fundamental que escapa al dominio de la automatización: el testing exploratorio.

Desde mi punto de vista esta actividad es fundamentalmente humana. Explorar significa adentrarse en lo desconocido, indagar, suponer, inspeccionar. Esto son actividades con un alto componente intelectual que no se pueden automatizar y es en este ámbito donde los humanos aportan un valor insustituible.

Ejecutar unos tests cases escritos en una plataforma no es explorar. Eso es seguir un camino prefijado y comprobar que el resultado es el correcto. Es como ir de excursión al monte siguiendo un track GPS con nuestro navegador. Esa actividad no se puede considerar bajo ningún punto de vista explorar ya que es totalmente predecible y automatizable. Adentrarse en un terreno desconocido, avanzar a través de él e identificar sus peligros es explorar. El resultado de esa exploración puede ser un nuevo mapa o track que se podrá automatizar posteriormente, si merece la pena.

La importancia de la telemetría en el Testing

En el modelo actual de entrega de valor, un elemento fundamental para detectar errores y proporcionar feedback es el uso de telemetría mediante distintas herramientas. Cuando se están haciendo despliegues a producción de manera frecuente, disponer de herramientas que detecten inmediatamente que se han producido problemas es fundamental de cara a recuperar el servicio cuanto antes. (Una de las métricas fundamentales en DevOps es el tiempo de restauración del servicio).

En un modelo DevOps, con el uso de la telemetría se comienza a hablar del concepto de que “Application Monitoring is the New Unit Testing” en el sentido de que en producción es la monitorización la que proporciona el feedback más rápido de que hay algún problema, al igual que en desarrollo es el testing unitario el que proporciona el feedback más rápido.

De esta manera el patrón de testing se transforma de pirámide a reloj de arena [1] :

Las distintas herramientas para logging, monitoring y alerting requieren de un artículo específico en el que hablaremos en próximas entradas de nuestro blog.

Conclusiones finales sobre Testing

El testing, aun siendo uno de los elementos fundamentales para el éxito de la implantación de DevOps en las organizaciones, sigue siendo uno de los más descuidados por parte de las organizaciones. Esto hace que muchos intentos de implementar una deployment pipeline terminen en fracaso. En este punto integrar correctamente en los equipos a personas con unos buenos skills y mindset relativos a testing es fundamental para el éxito de DevOps.

En artículos posteriores profundizaremos en distintos conceptos y herramientas de testing que nos van a ayudar en nuestra tarea de implementar DevOps con éxito. Conoce más sobre nuestros servicios DevOps.

Emiliano Sutil es Project Manager en Xeridia