Agilidad y Testing: Una mirada rápida a la construcción de un paradigma

La calidad es uno de los aspectos fundamentales dentro del proceso de desarrollo de software y como es de esperar, no ha sido indiferente a los cambios metodológicos de la industria. Hoy en día básicamente -y a grandes rasgos- podemos dividir las diferentes metodologías utilizadas en el proceso de creación de software (aunque no se restringen unicamente a ello) en dos grupos; las metodologías tradicionales y las metodologías ágiles. Las primeras enfocadas principalmente a cumplir un conjunto (y estricto) grupo de normas predefinidas que buscan poner énfasis en el seguimiento de buenas prácticas en la creación de software, por su parte, las segundas ponen énfasis en el dinamismo, los cambios y en la capacidad adaptativa del desarrollo de software. (Maida y Pacienzia, 2015). El éxito actual de las metodologías ágiles como scrum no es más que la respuesta a la realidad del contexto tecnológico moderno en el cual se exige a los equipos de trabajo una mayor adaptabilidad a los cambios y al dinamismo de la información y los negocios, en una mirada más amplia, esta realidad se corresponde con la rapidez misma del mundo y las sociedades altamente digitalizadas como la nuestra, no se podría ignorar tampoco la creciente tendencia que pretende darle un foco mas humano a las relaciones dentro de los equipos de trabajo, recordemos que en el caso de Scrum se cuenta con un manifiesto que en uno de sus doce principios indica… “Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados. ” frase que ejemplifica esta nueva visión de las relaciones entre integrantes de los equipos donde las antiguas estructuras rígidas que en muchos casos representaban micro jerarquías de otras aún mayores en la organización van quedando de lado para dar paso a relaciones ágiles que permiten una mayor adaptación a los desafíos… o al menos eso pretenden.

La aplicación de una metodología ágil implica a su vez una implementación de una filosofía de trabajo pensada en las personas, no en los procesos. Es por ello que, en los equipos ágiles se fomentan ciertos valores propios y aplicables a cualquier forma de trabajo en grupo donde las personas representan un factor fundamental del proceso, como la independencia, la confianza y el respeto. Estos valores (entre otros) se llevan a la practica en una forma particular de trabajar el desarrollo de aplicaciones, en donde, por ejemplo se genera una nueva relación con el cliente, el cual pasa (o eso se espera) a formar parte del equipo. Bajo este nuevo paradigma, fue necesario replantear además la forma en la que se realizaban las pruebas de software. Si en las metodologías tradicionales la -estricta- planificación con gantt (o cualquier otra) le daba un tiempo definido a la etapa de pruebas al final del ciclo de desarrollo con N iteraciones posibles, en agilidad se busca que el testing sea parte natural del propio desarrollo desde un inicio, con esto quiero decir que el testing (ágil) no existe únicamente en una etapa dada al final de la construcción, sino más bien, que existe y se ejecuta durante todo el proceso de desarrollo como una parte nativa del mismo desde el momento de la planificación.

Esta nueva filosofía aplicada al testing planteó nuevos desafíos y cuestionamientos sobre el propio proceso de calidad; por ejemplo, sobre el el conteo de iteraciones de la etapa de pruebas ¿Qué objetivo tendría un control de iteraciones si buscamos adaptabilidad al cambio del testing durante todo el ciclo de desarrollo y este es tan proclive a la actualización de los requerimientos? En su lugar, el testing agile itera indeterminadamente previo, durante y post construcción de las soluciones de software, esto conlleva diversos beneficios, entre ellos; capacidad de identificar bugs en etapas tempranas del desarrollo, construir pruebas adaptativas a los cambios del negocio, testear de forma incremental en conjunto con el desarrollo, menor costo, posibilidad de un feedback más rápido a los clientes, reduce la documentación y el tiempo para crearla y reutilización de pruebas (un beneficio adicional cuando sumamos automatización) entre otros.

Cabe además señalar, como mencionan Serna, Martinez y Tamayo en su trabajo “Una revisión a la realidad de la automatización de las pruebas de software” (2021), uno de los factores más llamativos y útiles del testing ágil es la integración de las pruebas automatizadas, las cuales se pueden comenzar a construir incluso antes de que la primera línea de código del desarrollo de la aplicación esté escrita y por tanto permiten ir testeando continuamente durante todo el desarrollo, su mayor impacto (uno de ellos al menos), es la factibilidad de encontrar errores tempranamente, al respecto, estudios como el de Hossain (2018) han demostrado que esta capacidad de encontrar errores desde las etapas primarias del desarrollo impacta positivamente en los tiempos de entrega y costos del proyecto. En resumen, Lo que antes era posible solamente testearlo en la etapa de pruebas una vez la solución estuviese construida, hoy, con el testing ágil y la automatización de pruebas es posible corregirlo incluso en la misma etapa de desarrollo.

Para ello, en el testing ágil construimos nuestras pruebas utilizando diversas tecnologías que nos ayudan a construir con calidad; como BDD (Behavior Driven Developmen) que en conjunto a su lenguaje programático Gherkin nos permiten crear escenarios de prueba con objetivos específicos donde cualquier integrante del equipo (incluido los usuarios) puede comprender fácilmente el paso a paso y objetivo de la prueba incluso antes de desarrollar una sola linea de código del test como tal. El uso de este tipo de herramientas (o técnicas… o procesos) y otras como TDD y ATDD nos permiten comenzar a trabajar en un nuevo paradigma de calidad en nuestros equipos de trabajo, donde si bien el testing ágil se integra naturalmente al desarrollo del software, es el propio equipo ágil quien vela, en su conjunto por la calidad del producto; esto significa (por ejemplo en scrum) construir historias de usuario con criterios de aceptación bien definidos, comprendidos y estudiados por el equipo en conjunto evitando ambigüedad o “pozos de incógnitas”, incluir pruebas en las etapas de desarrollo, la capacidad de ejecutar las pruebas automatizadas (o manuales) en ambientes lo más parecidos a producción, las pruebas regresivas automatizadas y la certificación del productos por parte del usuario ayudado por lo construido en el proceso completo de calidad, entre otros. Este que es un tema muy interesante de abordar y que algunos autores ya mencionan como algunos de los desafíos de la post agilidad, será sin duda motivo de una revisión mas profunda a futuro. Pero retomando… El objetivo de esta nueva filosofía del testing ágil para quienes trabajamos día a día promoviendo la calidad del desarrollo en nuestros equipos de trabajo es precisamente esto; hacer de la calidad una labor que debe estar presente desde la planificación hasta el despliegue final del producto y en el que cada integrante del equipo es igual de responsable y relevante que los demás. Este es uno de los desafíos modernos del testing en agilidad, pues plantea una nueva forma de trabajar como “QA” que aplica mas allá de la planificación y ejecución de pruebas (permitanme simplificarlo absurdamente), y comprende una forma completa de gestionar la calidad dentro del equipo ágil y dentro de todas las fases del desarrollo, desde la planificación inicial hasta la puesta en producción.