Paula
Carluccio

Cuando una épica queda lista para QA, el plugin lee todo lo que tiene en Jira y mira las pantallas en Figma. Con eso crea un ticket de análisis funcional: de qué se trata, las historias con sus criterios y los puntos que hay que aclarar con la PO.

También escribe los casos en Xray, en Gherkin: uno por funcionalidad y con una sola validación cada uno. Quedan en una carpeta “Por revisar”. No cambia nada de los tickets originales, solo los lee.

Las decisiones siguen siendo del equipo: aprobar, ejecutar o automatizar lo decide una persona.

Para analizar bien una falla, un agente tiene que conocer el proyecto. Este buscador le acerca lo que necesita: los steps y las pages que ya existen, los escenarios, el historial de ejecuciones y el código de la aplicación.

Busca de dos formas y junta los resultados: por palabras (BM25) y por significado, con embeddings de un modelo que corre en mi propia máquina con Ollama. Si el modelo no está disponible, sigue funcionando solo con palabras.

Está escrito en un solo archivo Java, sin librerías de afuera. El código de la aplicación es de solo lectura: los agentes lo consultan, no lo modifican.

Cuando termina una ejecución, el análisis corre solo dentro del pipeline. Agrupa las fallas parecidas, mira la captura de pantalla, cómo está armada la página y el registro de la ejecución, y las clasifica: locator que cambió, posible bug del producto o problema de ambiente. También dice qué tan seguro está.

Trabaja con permisos de solo lectura y tiene un respaldo con reglas, así que el reporte sale aunque la IA no responda.

Antes, para saber cómo había salido una ejecución, teníamos que entrar al pipeline, bajar el reporte y revisarlo a mano. Llevaba tiempo y era más difícil seguir los casos que habían fallado.

Le propuse al equipo automatizar ese seguimiento con Python y Power Automate. Ahora, cuando termina el pipeline, el equipo recibe en Teams un resumen con el análisis de la IA y los links a Jira. Los resultados también se guardan solos en una base de datos, donde revisamos las fallas y anotamos su seguimiento.

Además hice una app en Power Apps para ver los resultados por build, las fallas por módulo y los bugs conocidos.

Los resultados estaban repartidos en varios reportes. Era difícil compararlos y ver qué pasaba con el tiempo.

Armé un proceso que toma los resultados de cada ejecución, se queda con lo que sirve, lo ordena y lo guarda en una base de datos. También resolví los reintentos: un mismo caso no se registra dos veces ni cambia los números.

Ahora puedo ver cada ejecución por módulo y tipo de usuario, revisar las fallas y detectar las que se repiten. Aprovechamos datos que las automatizaciones ya generaban para decidir mejor.

La automatización de pruebas es donde más experiencia tengo. Puedo armar un framework desde cero: primero entiendo cómo funciona el producto, sus reglas de negocio y qué necesita validar el equipo.

Después decido qué conviene automatizar y cómo ordenar las pruebas. Escribo el código para que sea claro, fácil de mantener y pueda crecer con el producto.

Trabajé en automatización web, mobile y de APIs, desde preparar los datos hasta analizar los resultados.

También armé pipelines de CI/CD en Bitbucket Pipelines, con ejecución en paralelo, reintentos y controles de calidad, y mentoreo a gente del equipo de QA.