La charla fue impartida por Paola Aguirre durante la jornada del Testing en Chile. La oradora se define como una apasionada del mundo del testing y la calidad de software. Su experiencia se centra en acompañar a equipos y clientes en la búsqueda de una Calidad de Software (QA) que sea eficiente, automatizada y alineada a las necesidades del negocio.
El objetivo central de la conferencia fue explicar la evolución del rol del tester, detallando la transición necesaria desde un enfoque de testing tradicional hacia un modelo ágil, y destacando cómo la Inteligencia Artificial (IA) puede integrarse y colaborar activamente en la búsqueda de soluciones ágiles para optimizar la calidad del producto.
1. El paradigma del testing: se lo tradicional a lo ágil
La expositora comenzó su análisis estableciendo una distinción fundamental en la mentalidad de los equipos: la diferencia entre «ser ágiles» y «hacer ágiles».
Hacer ágiles (Implementación de herramientas y metodologías)
El concepto de «hacer ágiles» se refiere a la aplicación literal de metodologías y la utilización de herramientas específicas. Esto incluye el uso de Scrum, BDD, TDD, la implementación de artefactos específicos y la realización de ceremonias definidas, como la daily o la reunión de retrospectiva (retro). La oradora señaló que, aunque estas prácticas son comunes y necesarias, representan solo una parte del camino hacia la verdadera agilidad.
Ser Ágiles (Aplicación de Principios y Búsqueda de Soluciones)
Por otro lado, «ser ágil» implica ir «un poquito más allá». Este enfoque se centra en la aplicación genuina de los principios de la agilidad y en la búsqueda constante de soluciones efectivas para los desafíos que se presentan.
La expositora criticó la tendencia, observada en muchos equipos que solo «hacen ágiles,» de reducir procesos esenciales bajo la excusa de la agilidad. Por ejemplo, líderes que demandan pasar rápido el desarrollo porque «somos ágiles,» o equipos que omiten documentación diciendo «no hagamos documentación porque somos ágiles». Paola Aguirre enfatizó que esto es incorrecto: es necesario documentar y realizar reuniones, pero el foco debe estar en que estas sean ágiles, rápidas y concisas, siempre buscando el resultado y el valor agregado que se le dará al producto y al usuario final.
1.1. Los Problemas Inherententes del Testing Tradicional
Aguirre detalló los síntomas típicos y las fricciones que surgen en un entorno de testing tradicional:
1. Pruebas Tarde y Solo para Producción: Las pruebas suelen realizarse con el único propósito de salir a producción.
2. Desfase de Sprints: Frecuentemente, el equipo de QA no logra terminar todas las pruebas dentro del sprint actual. Esto resulta en testers que, en el sprint en curso, están probando funcionalidades que corresponden al sprint anterior.
3. Aislamiento y Baja Comunicación: Existe una separación clara entre el equipo de desarrollo y el equipo de testers. Los desarrolladores trabajan de forma aislada, con poca comunicación con los testers, y a menudo responden preguntas de testing solo al día siguiente.
4. Cultura de la Culpa: Se produce una «pelea constante» y el «juego de la culpa,» especialmente cuando un error llega a producción. La reacción inmediata es buscar «¿quién fue el que lo probó?».
5. Falta de Especificaciones y Conocimiento: Los testers a menudo carecen de especificaciones claras y conocimiento profundo sobre lo que deben probar. Se ven obligados a probar algo sin tener claridad sobre el objetivo real de la funcionalidad.
La oradora ilustró esta cultura de la culpa con un ejemplo personal, donde el Product Owner (PO) insinuó que levantar defectos aplicaba negativamente a las métricas del desarrollador. También mencionó el extremo opuesto, donde un tester decidió no levantar defectos para no perjudicar a un desarrollador novato. Paola Aguirre subrayó que ambos enfoques son perjudiciales, ya que es crucial levantar métricas para entender qué está sucediendo, y, lo más importante, cómo solucionarlo y prevenirlo en el futuro.
1.2. Características y Objetivos del Testing Ágil
El testing ágil implica la aplicación de los principios de agilidad y la realización de testing durante todo el ciclo de vida del software. Este enfoque busca resolver los problemas del modelo tradicional mediante la integración y la prevención.
Componentes Clave del Testing Ágil:
• Equipo Único: En lugar de equipos separados, hay un único equipo ágil desarrollando el producto.
• Responsabilidad Compartida: La calidad es responsabilidad de todo el equipo, no solo del tester.
• Cambio de Enfoque ante Fallos: La pregunta deja de ser «¿quién lo probó?» y migra hacia «¿qué prueba nos faltó poner?» o «¿cómo podemos evitarlo la próxima vez?». Es fundamental aprender de los defectos productivos para prevenir futuras ocurrencias.
• Prevención sobre Detección: El objetivo principal es prevenir errores, en lugar de simplemente detectarlos. El rol del tester evoluciona: ya no es el encargado de «romper el sistema,» sino el que «construye el sistema de calidad».
Beneficios Estratégicos:
El testing ágil genera beneficios tangibles en el negocio:
1. Reducción de Costos y Tiempos: Se logra testeando lo antes posible. La oradora recordó el conocido concepto de que el costo de corregir un error aumenta exponencialmente a medida que pasa de una etapa a otra en el ciclo de desarrollo.
2. Mayor Calidad y Satisfacción del Cliente: Se busca entregar un producto de mayor calidad.
3. Inclusión de Pruebas Esenciales: Aguirre enfatizó la necesidad de integrar pruebas de adaptabilidad digital (accesibilidad) y pruebas de estrés (performance) en el día a día. Mencionó que muchas empresas se están olvidando de la población con discapacidad (citando que el 13% de la población tiene alguna) al no realizar pruebas de adaptabilidad digital. También destacó la importancia de las pruebas de estrés antes de salir a producción para verificar que el sistema no se vea afectado.
4. Flexibilidad: Se debe tener flexibilidad para adaptarse a los cambios de requerimientos. El equipo no debe frustrarse, sino negociar y buscar cómo integrar el cambio, aprovechando el tiempo ya ganado.
2. BDD (Behavior Driven Development) como Facilitador
Paola Aguirre definió BDD como una forma de trabajo o metodología. Hizo hincapié en que BDD no se limita a la automatización de casos de prueba utilizando herramientas como Cucumber o a la simple escritura de código.
2.1. El Proceso Colaborativo del BDD
La aplicación efectiva de BDD comienza en las etapas tempranas del sprint, específicamente durante el refinamiento de las historias de usuario.
1. Reunión de los Tres Amigos (Colaboración): El tester, el desarrollador y el Product Owner (PO) se reúnen para trabajar en conjunto y definir los criterios de aceptación de la historia. Este momento es clave para aplicar BDD.
2. Formato Gherkin: Los criterios se definen utilizando el lenguaje Gherkin, estructurado con las palabras clave Dado (Given), Cuando (When), y Entonces (Then), además de «Y» (And) y «Pero» (But).
3. Horizonte Claro: Al tener estos criterios definidos y claros, el equipo establece un «horizonte» de lo que se debe construir y probar como mínimo al final del sprint.
4. El Rol del Tester como Puente: En este proceso, el tester cumple una función esencial como puente de comunicación, hablando los «dos idiomas»: el lenguaje de negocio del PO y el lenguaje técnico del desarrollador.
2.2. Automatización Temprana (Shift Left)
El enfoque BDD facilita la práctica del Shift Left. Una vez que los criterios de aceptación están claros y los testers conocen los nombres técnicos de los elementos que se van a utilizar en la interfaz o el sistema (ya sea una página, una API, etc.), pueden empezar a automatizar las pruebas.
Es crucial el concepto de Desarrollo Dirigido por Pruebas (TDD) en este contexto. El tester puede automatizar los casos de prueba de aceptación sin necesidad de que el código productivo esté listo. Es el desarrollador quien, posteriormente, debe codificar el producto para que las pruebas ya diseñadas pasen exitosamente.
Este enfoque de trabajo permite al equipo ganar tiempo. Cuando el desarrollo se completa, el equipo ya tiene las pruebas automatizadas de los criterios de aceptación, lo que permite pasar más rápidamente a otro tipo de pruebas, como las de usabilidad, digitalización o estrés, e incluso terminar el sprint entregando dos o tres historias de calidad totalmente automatizadas.
3. La Inteligencia Artificial (IA) al Servicio de la Calidad
La charla de Paola Aguirre se adentró en cómo la IA puede optimizar y agilizar las tareas de QA. Presentó un Bot desarrollado por Ecosistema como ejemplo de solución.
3.1. Automatización de Criterios de Aceptación
El Bot utiliza IA generativa para facilitar la creación de criterios de aceptación. El flujo operativo es el siguiente:
1. Input: El usuario carga la historia de usuario en el Bot.
2. Generación: La IA procesa la información y genera automáticamente los criterios de aceptación en lenguaje natural. La oradora aclaró que esta función podría replicarse con cualquier IA generativa, siempre y cuando se le proporcionen las condiciones y el prompt necesario.
3. Negociación: Los criterios que el Bot genera no son definitivos, sino que pueden ser editados y negociados con el PO en la misma plataforma.
Al final de este proceso, los casos de prueba quedan armados en Jira utilizando la herramienta Xray.
3.2. El Flujo de Automatización y CI/CD
La integración técnica del testing se realiza a través de un flujo estructurado:
1. Gestión en Xray/Jira: Los casos de prueba se gestionan en Jira, donde se les asignan etiquetas (tags) que clasifican su tipo (ej. regresión, smoke test, funcionalidad particular). Xray es la herramienta que permite este control.
2. Exportación a Cucumber: Xray posee una funcionalidad que permite descargar los casos de prueba definidos en Gherkin como archivos feature de Cucumber, los cuales están listos para ser utilizados por las herramientas de automatización.
3. Herramientas de Ejecución: Estos archivos feature son utilizados por herramientas de automation como Catalon o Selenium.
4. Integración Continua (CI/CD): El proceso se integra con sistemas CI/CD (como Jenkins o Azure DevOps).
◦ Despliegue y Smoke Tests: Al desplegar la funcionalidad en el ambiente de testing, se ejecuta automáticamente un pipeline con los SMOKE tests marcados con sus respectivos tags. Esto permite determinar de inmediato si el ambiente está listo para continuar con el testing o si debe regresar a desarrollo.
◦ Ejecución de Regresión: Posteriormente, el equipo puede ejecutar la regresión completa o solo los casos de prueba de la historia de usuario específica, seleccionándolos mediante sus tags en Jenkins o Azure DevOps.
5. Reportería: Los resultados de la ejecución se envían de vuelta a Xray. La oradora recomendó el uso de herramientas de reportería como Azure Report, señalando que es más intuitiva y puede configurarse para enviar el informe de Cucumber por correo electrónico a los Product Owners y otros interesados.
3.3. Colaboración Específica de la IA
La IA no solo ayuda a generar criterios, sino que colabora en diversas tareas técnicas:
• Generación de Datos de Prueba: La IA puede generar datos de prueba, o asistir al tester estructurando las consultas necesarias para obtener datos de las bases de datos. Aunque el conocimiento de SQL sigue siendo necesario, la IA puede colaborar en esta tarea.
• Asistentes para Testing: Se pueden crear asistentes personalizados para cada etapa del testing, donde el usuario carga la información y obtiene resultados directos.
• Pruebas Visuales: La IA es particularmente útil en las pruebas visuales, especialmente aquellas que son difíciles de detectar para el ojo humano.
◦ Herramientas como Catalon ya poseen una funcionalidad que valida si hay cambios entre una versión del front y otra (una versión uno versus una versión dos) o compara la interfaz con un diseño de Figma.
◦ Para aplicaciones móviles, existe Applitools con AG, el cual requiere solo tres o cuatro líneas de código adicionales en la automatización para comparar una imagen base con la imagen de la nueva prueba.
• Optimización de Tiempo y Codificación: La IA reduce el tiempo tanto en la ejecución como en la codificación de las pruebas automatizadas. Existen bots que son capaces de escribir el código Cucumber a partir de lenguaje natural, reutilizando estructuras existentes.
4. Evolución del Rol QA y Recomendaciones
La charla concluyó abordando la transformación del perfil del QA ante la llegada de la era inteligente.
El Antiguo y el Nuevo QA:
Anteriormente, el QA era valorado principalmente por su conocimiento de negocio (ej. alguien que llevaba 10 años en la empresa). Hoy, aunque el conocimiento de negocio sigue siendo necesario, el rol requiere una combinación de habilidades específicas:
1. Habilidades Personales (Soft Skills): El QA debe ser comunicativo, curioso, e investigador. Debe estar presente y participar activamente en las reuniones (como los refinamientos).
2. Conocimientos Técnicos: Es obligatorio para el QA moderno saber de automatización y utilizar la Inteligencia Artificial. Si el tester no es un especialista en codificación, debe saber al menos qué es lo que se necesita automatizar y apoyarse en especialistas para lograrlo.
Recomendaciones Finales (Shift Left y Estrategia):
La oradora ofreció varias recomendaciones para implementar una estrategia de calidad ágil:
• Realizar Pruebas lo Antes Posible: Aplicar la filosofía Shift Left o BDD.
• Incorporar Analistas Tempranamente: Los analistas de prueba deben incorporarse al equipo desde las etapas iniciales de la definición del producto.
• Planificación Integral: La inclusión del testing debe asegurarse en la planificación general del proyecto. La planificación, que incluye el presupuesto, debe contemplar la presencia del tester desde el inicio.
• Revisión de Pruebas Unitarias: Se debe permitir que los analistas de prueba revisen las pruebas unitarias. Esto actúa como una medida de aseguramiento adicional.
• Invertir el Cono de Pruebas: Se debe «dar vuelta al cono de helado», es decir, realizar muchas más pruebas unitarias y pruebas básicas automatizadas. Esto libera tiempo del tester para que pueda enfocarse en pruebas más complejas y de alto valor, como las pruebas exploratorias y de estrés.
