¿Les ha pasado que la mejor forma de entender nuevos conceptos, es acudiendo a la metáfora de cómo sería la situación expuesta, con un ejemplo relacionado con autos?

A raíz de esto, cuando he tenido la oportunidad de explicar qué es Testing Continuo en TSOFT hacia nuestros colaboradores y clientes, se me ocurrió ver la manera de utilizar mis dos grandes pasiones: Calidad de Software y los Autos.

A continuación, mediante una carrera de 3 vueltas, podrán comprender los siguientes puntos asociados a lo que llamaremos, la carrera del Testing Continuo:

1. La relación con el Time to Market.
2. La evolución de los equipos de QA.
3. Su propósito y significado.

Primera Vuelta: Acelerando hacia el Time to Market

Para iniciar esta primera vuelta, es importante recordar la siguiente frase de Klaus Schwab:

En el mundo actual, no es el pez más GRANDE que se come al pez más CHICO, es el pez más RÁPIDO que se come al pez más LENTO

Con los autos ocurre lo mismo, ya que se piensa que el auto más potente y grande será el ganador, pero la realidad actual es que un auto bien optimizado y no necesariamente grande, podrá demostrar ser el más rápido.

En las compañías que desarrollan software es igual, en donde no necesariamente los que tengan grandes presupuestos y gran cantidad de colaboradores serán los ganadores, ya que los más pequeños también tendrán incluso una mayor capacidad de adaptación hacia lo nuevo que requiere el mercado y el negocio, mediante el impulso de una cultura de calidad a través de un proceso de Testing Continuo, el cual permitirá ser los más rápidos.

Segunda Vuelta: El equipo de QA a máxima velocidad

Imaginen, por un momento, la siguiente situación que sucede en las compañías:

«El equipo de desarrolladores comienza a construir este software solicitado por el negocio, con la mayor velocidad posible, como si fuera un auto de Formula 1. Llega el momento de decirles al equipo de Testing, que certifiquen este nuevo sprint o incremento ya desarrollado. Sin embargo, este equipo no tiene la misma velocidad de reacción que los desarrolladores. Como consecuencia, se convertirán en un cuello de botella, generando demoras en la entrega. Finalmente, para entregar a tiempo la solicitud del negocio, se fuerza el pase a producción, conllevando a salir con insuficiente calidad. A raíz de esta decisión, ocurren defectos productivos que generaron perdidas económicas, impactando a la organización.»

Para evitar este tipo de situaciones, el equipo de QA tendrá que subirse también a esta ola de cambio, que conllevó a tener la capacidad de correr como un Formula 1, decidiendo ir a la misma velocidad que el desarrollo, para que pudieran realizar ambas tareas en conjunto.

Este proceso de cambio y evolución, se logrará gracias a la implementación de Testing Continuo.

¿Qué objetivo cumpliremos mediante esta evolución en las capacidades del equipo QA?

En los autos ocurre que si se daña el alerón delantero a raíz de un choque, el equipo estará listo para desplegar la pieza en tiempo récord al pasar por pits para que el auto siga funcionando en la carrera. O si se necesita desplegar una nueva configuración o componente del auto, se podrá tener lista en tiempo record para la siguiente carrera.

En el mundo del desarrollo de software, ocurrirá lo mismo, ya que la capacidad de cada célula de ir desarrollando mejoras, certificarla y desplegarla en producción lo más rápido posible, será gracias a la evolución de los equipos de QA mediante el proceso de Testing Continuo.

Tercera Vuelta: Primer lugar en el podio

En el mundo automotor, los circuitos poseen túneles los cuales los autos deben ingresar y salir con la mayor velocidad posible para subir posiciones y poder ganar la carrera, demostrando que son los más rápidos y eficientes a la hora de correr sus autos.

En el mundo del desarrollo de software, para lograr estar en el podio con el primer lugar, se deberá utilizar un túnel automatizado que llamaremos pipeline, el cual permitirá entrar y salir de este con la mayor velocidad posible y de la manera más eficiente, incluyendo stages con prácticas de calidad que garanticen que siga operando una vez que desarrollemos una nueva funcionalidad o corrección.

Con base en esto, el proceso que ocurrirá es el siguiente:

1. Al desplegarse esta mejora mediante el commit en el ambiente de desarrollo, se ingresará al túnel generando lo que llamaremos Integración Continua, en donde se ejecutarán las pruebas unitarias e inspección de código, certificando a nivel de «Calidad del Código».
2. Posteriormente, se ejecutará la Entrega Continua, que conllevará a continuar con las pruebas funcionales y no funcionales, certificando a nivel de «Calidad del Sistema» y de esta manera, tener ya listo el código certificado en esta etapa.
3. Por último, para cerrar, utilizaremos lo que llamamos la práctica de Pruebas Productivas, para certificar a nivel de «Calidad del Release» y conseguir una Operación Continua.

Este proceso automatizado, que permitió acelerar la entrega del software y certificar punta a punta mediante cada una de las prácticas de calidad expuestas, finalmente es lo que consideramos como Testing Continuo, el cual impulsará la calidad desde el origen, entregando feedback temprano hacia todos los equipos de la célula, ya sean desarrolladores y usuarios de negocio, para evaluar rápidamente si el requerimiento solicitado tendrá el valor esperado para mejorar la experiencia del usuario.

Cierre: La celebración del triunfo

Para dar término a esta increíble carrera y festejar el triunfo, será importante tener en consideración las siguientes lecciones aprendidas que conllevaron a evolucionar este mindset de calidad de software hacia un Testing Continuo:

• El rol de QA deberá estar presente desde el inicio del desarrollo del Software hasta su salida a producción, impulsando cada una de estas prácticas para poder generar lo que llamamos una Cultura de Calidad en la célula de trabajo.
• La calidad del Software no solo se mide en el ambiente QA, sino en todo el ciclo de vida del software, incluido producción, ya que para lograr ganar la carrera, se deberá impulsar la «Calidad del Código», «Calidad del Sistema» y «Calidad del Release», permitiendo hacer fluir estas prácticas durante todo el ciclo de vida del desarrollo de software.

¿Qué conclusión podemos llegar si queremos resumir lo que es Testing Continuo en pocas palabras? La siguiente definición es la que me pareció más acertada:

Testing Continuo se considera como la capacidad de acceder instantáneamente al riesgo de una nueva versión o modificación antes de que afecte a los clientes.

Esta definición cubre los siguientes puntos resaltados, los cuales fueron expuestos durante este artículo:

• Capacidad: La evolución y formación de estos equipos de QA transformados.
• Instantáneamente: La obtención de resultados con el menor Time to Market.
• Riesgo: El feedback temprano y continuo para evaluar el impacto junto al equipo de negocios antes de desplegar en producción.
• Antes: La mitigación y anticipación de incidentes que puedan impactar al usuario final.

En TSOFT, nos encontramos evangelizando este tipo de conocimientos en nuestros colaboradores y clientes, para poder impulsar una cultura de calidad, que permita acelerar y optimizar los procesos de desarrollo de software, apuntando obtener un menor time to market con calidad punta a punta.

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