Testing…testing. Uno…Dos. Testing…testing

¿Tienes problemas con la calidad de los productos y servicios de software creados por tu equipo? El realizar pruebas demanda días o incluso semanas de esfuerzo? Pues no estas solo, todos pasamos por esto… pero solo los valientes (como tú y yo 🦁) encontramos la solución.

Seamos honestos, ¿a quién le gusta repetir la misma tarea aburrida ocho horas al día, cinco días por semana? Personalmente, preferiría ahorcarme con el cable cargador de batería del smartphone que realizar dicha tarea por diez minutos☠.️

Si tu también experimentas eso, entonces ¿por qué obligamos a otras personas a realizar dicha tarea? Me refiero a obligarlos a verificar una y otra y otra vez la calidad de una aburrida aplicacion. ¡Y no lo tomes mal! Puede que estes desarrollando aplicaciones de Realidad Virtual para la NASA, el siguiente Candy Crush o Inteligencia Artificial para Poker. Tarde o temprano, la emoción se desvanece y se torna en aburrimiento.

El inevitable tedio

Actualmente, la vida cotidiana esta impregnada de automatización. Cafeteras eléctricas para proveerte “motivación líquida”, microondas para calentar tu merienda y Tinder para…ya tú sabes. Si nuestra vida es optimizada gracias a la automatización, ¿Por qué cuando desarrollamos código, seguimos utilizando nuestras manos para comprobar su calidad?🤔

Uno de los pecados capitales en equipos de desarrollo es codificar funcionalidad o hot-fixes sin acompañarlos de sus respectivos tests automatizados. Y dirás: “Pero JJ, ¡No tenemos tiempo para crear tests. Debemos entregar aquello que prometimos ya!”. A lo cual respondo: “¿Prometiste entregar un producto de calidad o prometiste entregar deuda técnica?”

(Interludio para permitir la percolación de la idea……

…. Fin del interludio)

Bueno, si sigues leyendo hasta acá, está confirmado que eres de l@s valientes, así que veamos como resolver esta situación.

Mano vs Máquina

Claramente nuestras capacidades humanas no incluyen predicción. Es por eso que muchos equipos de desarrollo, cuando calculan el esfuerzo necesario para realizar pruebas antes de un Release, piensan linealmente en lugar de comprender que están ante un escenario no lineal.

Los tests automatizados se comportan como una combinatoria matemática donde mientras más funcionalidad añades, más combinaciones necesitas probar. Por esto, la forma inteligente de escalar tus habilidades de testeo, es a través de la continua ejecución de tests automatizado.

Considera lo siguiente:

• Más features implican más combinaciones.
• Más combinaciones implican más manos necesarias para testear.
• Más manos necesarias implican más tiempo consumido y más costo.

Y compáralo contra lo siguiente:

• Más features (que incluyen tests automatizados) implican más combinaciones
• Más combinaciones implican misma cantidad de manos para testear
• Misma cantidad de manos implica testeo automatizado en paralelo y costo reducido.

¡No! no planteo despedir a nuestros ingenieros de calidad. Al contrario, la forma de nutrir las carreras profesionales de estos, así como también de los desarrolladores, es la de requerir (mínimamente) conocimiento sobre herramientas de automatización.

Dejemos a las máquinas hacer lo que mejor hacen, repetir incansablemente. Dejemos a los humanos hacer lo que mejor hacen, crear.

Continuous Testing

Después de analizar bastante el Ciclo de Continous Integration\Continuous Delivery que representa a DevOps entendí que si no se toma en cuenta la mentalidad de “fallar rápido”, existe una mala interpretación del bucle acerca de la función de los tests y podríamos volver a pensar de que las pruebas son una etapa posterior a la codificación (alias: “Desarrollo en Cascada”). Por este motivo, para realmente reflejar la realidad de los equipos que practican DevOps y Continuous Testing efectivamente necesitamos un ciclo similar a este:

Se tiende a ver al testing como si fuese una fase dentro de CI\CD, sin embargo es algo que se esparce por varias etapas verificando que en cada una estemos asegurando la calidad (o en otras palabras, tratamos de fallar lo más rápidamente posible).

Esto es a lo que se conoce como Continuous Testing y funciona como interés compuesto en una cuenta bancaria: mientras mas tests automatizados creas (inversión), menos esfuerzo humano invertirás en el futuro para cubrir una mayor área de extensión de tu aplicación (ganancia).

Los tests automatizados son distribuidos a lo largo del flujo y agrupados de acuerdo a su tipo, por ejemplo:

• Al planear un feature, la forma mas rápida de validar si la idea tiene o no una probabilidad de éxito es crear un prototipo y validarlo con los usuarios. (Vale, esto no es automatizable, pero estarás de acuerdo en que es una buena idea el probar la recepción del feature en esta fase que descubrir que es un fracaso en Producción).
• Luego de codificar, los Unit Tests y Tests de Análisis Estático de Código representan el primer control de calidad automatizado, además de ser baratos y rápidos en ejecución.
• Una vez compilado el producto, realizamos Tests de Integración y Tests de Aceptación de Usuario (UAT). Es éste tipo de pruebas las que mayormente vienen a la mente cuando se hablan de “la fase de Tests”. Por lo general, los UAT imitan la interacción del usuario con la aplicación, lo cual los hace más lentos que los anteriores.
• Cuando un Producto se encuentra funcionando en un ambiente que refleja a Producción, podemos ejecutar los tests automatizados de Seguridad, Stress y Performance.
• Finalmente tenemos a la Ingeniería del Caos, para ayudarnos a probar la resiliencia de los servicios que tenemos en producción.

El Reto

Aunque no lo creas, la parte complicada de aplicar Continuous Testing no se encuentra en el uso de las tecnologías, sino en lograr que el hábito de crear tests automatizados sea parte de la cultura de tu equipo. Es similar a cuando tu dentista te recomienda cepillarte los dientes tres veces por día. Tú sabes que tienes que hacerlo y lo haces por varios días pero dejas el hábito en una semana. Lo siguiente que sabes es que estás visitando al dentista nuevamente para curarte las caries.

Incorporar buenos hábitos va en contra de nuestro comfort, sin embargo al internalizarlos, damos paso a la creación de sistemas mentales y grupales que aseguran que tarde o temprano seamos exitosos.

Cualquiera crea software. No cualquiera crea software de calidad.

Keep on learning and testing.

¿Qué tests automatizados tiene tu equipo?¿Qué tests pueden automatizar? Deja tus comentarios y ayudemos a crear el hábito de crearlos.

Y como siempre, por favor déjame tu feedback en este artículo. ¿Te fue útil?¿Qué aumentarías o quitarías?¿Otras sugerencias? También puedes enviarme un tweet a @jjruescas1 y colocar #DevOps al final para poder encontrarlo.🙂

¿Deseas conocer más sobre DevOps? No olvides revisar el curso “DevOps — Las Artes Marciales del Software” en Udemy.com.