¿Se han preguntado cuáles son las bases para lograr el correcto impulso de una cultura de Testing Continuo en el mundo de la Calidad del Software?

Mediante el siguiente artículo, y bajo la misma línea metafórica de la Fórmula 1 que se tuvo en mi publicación anterior de Testing Continuo, se expondrán 4 grandes desafíos que he observado en base a lo que ocurre actualmente en el mercado y que se están tratando de resolver por parte de las compañías para lograr el éxito de impulsar esta cultura de calidad.

Desafío 1.
Automatización de las pruebas

En la Fórmula 1, antiguamente el auto se debía depurar en la pista directamente de manera manual para ajustar su configuración. Posteriormente se utilizó la automatización mediante simuladores que validan el comportamiento de cada componente del auto por separado y en conjunto, ya sea el motor, aerodinámica del chasis, frenos, entre otras.

En el mundo de la certificación de software ocurre lo mismo, en donde pasamos de las pruebas manuales como por ejemplo en dispositivos móviles, hacia la utilización de herramientas para realizar la navegación de la aplicación desarrollada, permitiendo automatizar la mayor cantidad de pruebas que son repetitivas para optimizar el proceso.

¿Esto quiere decir que entonces el 100% de las pruebas serán automatizadas erradicando las pruebas manuales?

Esto es un pensamiento incorrecto, ya que por más que las herramientas puedan automatizar gran parte de las pruebas, existirá un grupo de casuísticas que deberán «explorarse» inicialmente antes de intentar automatizarse, de lo contrario la automatización será ineficiente.

Para lograr esto, entran en la ecuación las pruebas exploratorias o mejor dicho pruebas con «enfoque exploratorio», en donde mediante el conocimiento de negocio y expertise de calidad el referente de QA, podrá navegar y visualizar combinaciones de prueba que aún no son descubiertas, para posteriormente pensar en automatizarlas.

Desafío 2.
FEEDBACK

En las carreras se requiere un trabajo en equipo continuo y comunicativo, en donde por ejemplo el Ingeniero de Carrera, que vendría siendo como el Product Owner, se le debe dar:

• Feedback del comportamiento del auto(experiencia usuario)
• Detectar alguna mejora(requerimiento) que sea necesaria implementar para que la performance del auto sea la más optimizada.

De esta manera se podrá ganar la carrera que, para efectos del producto, será lograr el mejor time to market.

En el desarrollo de software ocurre lo mismo, en donde debemos lograr esta comunicación fluida entre todos los actores correspondientes que son parte de este ciclo iterativo.

El promotor de esto es el proceso de Testing Continuo, impulsado por el referente de QA, ya que permite interconectar cada fase del ciclo de vida de desarrollo de software, para obtener un feedback rápido y continuo hacia el negocio y todos los que desarrollan el producto, para determinar si está en condiciones de salir a producción.

Desafío 3.
RIESGO DE NEGOCIO

En la Fórmula 1 se debe analizar: telemetría del desempeño del auto, información del clima, temperatura de la pista, entre otras variables.

Estas, permitirán ir tomando decisiones tales como: qué neumáticos utilizar, cuándo entrar a pits, qué tipo de manejo realizar en cada sección y configuración del motor.

Todo esto, en base a la evaluación de riesgo de ganar segundos versus la posibilidad de cometer algún error que los haga perder posiciones.

En el desarrollo de software ocurre algo similar, en donde mediante la aplicación de este proceso de Testing Continuo ocurre la misma dinámica:

1. Se debe analizar el riesgo de negocio existente por cada tipo de desarrollo y por ende certificación a realizar.
2. Posteriormente se evolucionará de un modelo de certificación que busca un foco hacia la eficacia, ejecutando todas las pruebas posibles, hacia un modelo de pruebas eficientes, ejecutando lo justo y necesario en base a ciertos criterios asociado al riesgo que posee dicha aplicación y flujo de negocio.
3. Esto permitirá clasificar el valor de cada prueba y su impacto en la detección de algún defecto versus pruebas, que si bien se podrían ejecutar como parte de la regresión, esto ralentiza el proceso, lo cual afectaría el time to market y por ende la meta de ganar esta carrera.

En resumen, al aplicar este enfoque y proceso de Testing Continuo, la mentalidad del equipo debe ser priorizar las pruebas justas y necesarias y no siempre ejecutar todas las pruebas, independiente si están automatizadas o no, ya que no generarán eficiencia, lo cual se logrará mediante la evaluación del nivel de riesgo que se está adoptando en las pruebas.

Desafío 4.
VELOCIDAD

Para lograr que la carrera se pueda ganar, se debe tener la capacidad de ir a más de 300km/h en las rectas y poder tomar las curvas con la mayor velocidad posible, para ser el mejor y por ende, lograr el menor time to market.

En el desarrollo de software aplicando Testing Continuo ocurre lo mismo, donde para lograr la mayor velocidad se debe considerar optimizar distintas prácticas de prueba que permitan hacer un proceso más eficiente y rápido.

El sustento de aplicar este enfoque, está basando en la Pirámide de Cohn, en donde a mayor cantidad de pruebas de bajo nivel, la certificación y detección de defectos será menos costosa.

Es por esto que para lograr un correcto proceso de Testing Continuo, a nivel funcional, se busca lo siguiente:

• Las pruebas de Front-End sean las menores posibles, a pesar de estar automatizadas, ya que poseen un Fedback Lento y Mayor Esfuerzo
• Se deberá beneficiar y priorizar todo lo que corresponde a las pruebas de Servicios o APIs, ya que poseen un Feedback Rápido y Menor Esfuerzo.

Ahora bien, ¿Se podrá conseguir la mayor velocidad posible solamente mediante estas mejoras en el proceso?

En algunas ocasiones, cuando se busca mejorar la velocidad punta del auto, se suele acudir a lo que llamamos inducción forzada que puede ser incluir un turbo en el auto, que aumente la potencia y por ende su velocidad. Esto, lo llamaremos de alguna manera una componente que son los aceleradores de este proceso.

En el desarrollo de software, para poder lograr esta velocidad punta, se debe acudir a estos aceleradores, los cuales los interpretaremos como dos instancias o boost en donde el turbo del auto acelerará el motor para exprimir al máximo su desempeño.

Primer Boost:
Implementación de Test Data Management (TDM)

Como primer gran complemento, para lograr que este proceso de Testing Continuo fluya realmente a la mayor velocidad posible, deberá ser necesario poseer esta práctica de TDM que permita:

• Entender todas las dependencias existentes de los flujos a probar por cada sistema a nivel de los datos
• Automatizar la creación y/o búsqueda de los datos asociados a esos flujos
• Disponibilizar un proceso y plataforma que permita entregar de manera auto-atendida los datos necesarios por cada certificación

Esta práctica de TDM, permitirá mitigar la dependencia existente en la certificación asociado a este insumo tan requerido, que son los datos de prueba, para mitigar el cuello de botella asociado al proceso o personas encargadas de proveer estos.

Segundo Boost:
Implementación de Virtualización de Servicios (SV)

Como segundo gran complemento, para lograr que este proceso de Testing Continuo fluya realmente a la mayor velocidad posible, deberá ser necesario poseer esta práctica de SV que consiste en:

• Entender las dependencias existentes por cada flujo de negocio y sistema asociado a servicios a consumir por cada uno de estos.
• Automatizar mediante herramientas el comportamiento y respuestas de esos servicios a través de la virtualización.
• Despliegue del servicio virtualizado para que sea consumido por cada certificación y simular las respuestas del servicio original.

A través de esta práctica, se mitigará el cuello de botella asociado al ambiente necesario para poder hacer fluir la certificación y no depender de terceros para la habilitación de cada uno de estos servicios.

En resumen respecto a este último desafío, con estos 2 grandes aceleradores conseguiremos realmente esa velocidad punta de más de 300km/h que requiere el Testing Continuo para hacerlo realidad, ya que la certificación de cada una de las casuísticas elegidas fluirá sin contratiempos de datos y ambiente.

Caso de Uso

A continuación a modo de ejemplificar cómo sería un proceso que entregaría cobertura a cada uno de estos desafíos se detalla el siguiente caso de uso:

1. Se solicita por parte del negocio, desarrollar y probar una nueva funcionalidad del portal Web de una empresa de Retail, en donde se tendrán que automatizar los casos de prueba para ejecutar regresiones y acelerar el proceso de certificación. Para lograr esto, en primer lugar se entiende el requerimiento por parte de los equipos de calidad junto con el negocio y desarrollo, para estar alineados con la estrategia de pruebas que se adoptará. COBERTURA: FEEDBACK
2. El equipo utilizará un framework de automatización para poder crear los scripts que navegarán a través de las nuevas pantallas de la aplicación en la capa de interfaz de usuario y por otro lado se usará el framework para consumir los servicios que se construyeron o modificaron, para certificar esta capa de más bajo nivel. COBERTURA: AUTOMATIZACIÓN DE PRUEBAS + VELOCIDAD
3. Para elegir los flujos a automatizar, se procedió a analizar la estadística de transacciones más utilizadas, las que poseen mayor complejidad y por otro lado que posean por ejemplo movimiento de dinero, lo cual permite entender cuales serán de mayor prioridad y que generarán un mayor impacto positivo al detectar defectos de manera temprana mediante la regresión. Esto facilitará evaluar a nivel de riesgo cada automatización y por ende tomar una mejor decisión a la hora de elegir que automatizaremos y que no. Las casuísticas que no se automatizarán, tendrán un enfoque exploratorio para probar funcionalmente a nivel manual de manera eficiente. COBERTURA: AUTOMATIZACIÓN DE PRUEBAS + RIESGO DE NEGOCIO
4. Posteriormente, se realiza el lanzamiento automático de los casos de prueba cuando ya el equipo de desarrollo libere una nueva pieza de código a los ambientes de prueba, en donde para que estos funcionen de manera fluida, se procedió a cargar los scripts configurados con los datos generados mediante la plataforma de auto-atención que permitirán dar cobertura a las casuísticas configuradas en la ejecución. Adicionalmente, se dejaron habilitados los servicios virtualizados, para cuando los scripts que requieran consumir estos para avanzar en el proceso, no queden detenidos. COBERTURA: VELOCIDAD
5. Finalmente, cuando las pruebas terminen y se tenga claridad el estado de la certificación, mediante la visualización de los resultados en una herramienta de gestión de calidad, se procede a realizar la revisión con los equipos correspondientes del negocio y desarrollo, para evaluar si se pudo lograr el criterio de aceptación esperado, junto con el análisis de las incidencias que se pudieron encontrar durante el proceso. Con esta información, se tomará la decisión si está ya todo validado y listo para salir a producción. COBERTURA: FEEDBACK

Conclusiones

Para cerrar este artículo, podemos concluir que implementar un proceso y cultura de Testing Continuo no será algo trivial, tal como ocurre correr en la Formula 1. Sin embargo, mediante el impulso y superación de los 4 desafíos planteados, podrán construir las bases para el camino hacia el éxito de poder generar un producto de calidad en el menor tiempo posible, logrando el mejor time to market y por ende, ser los ganadores de esta increíble carrera a más de 300km/h.

Autor:
Rodrigo Andrés Montenegro Tagle
Gerente de Negocios DevOps & Líder Regional de Calidad (Built-In Quality)

—
¿Quieres obtener más información sobre nuestro portafolio Built-in Quality y sus servicios que impulsan esta cultura de Testing Continuo?

Escríbenos a: contacte@tsoftglobal.com