The Subtle Art of Herding Cats: Cómo convertí el caos en un proceso de pruebas repetible Parte 3 de 4
En esta entrega explico cómo validé la idea de que los patrones BDD universales funcionan cuando se separan los detalles de implementación del comportamiento humano observable. Aquí presento un resumen práctico, ejemplos reales y lecciones aprendidas durante la puesta en marcha de un flujo que va desde un ticket de Jira hasta pruebas automatizadas ejecutables.
Principio universal: si dos empresas hacen lo mismo, el escenario BDD es el mismo. Aunque BMW y Mercedes implementen configuradores con APIs y microservicios diferentes, la intención del usuario es igual: seleccionar paquetes, ver el precio actualizado y detectar conflictos. Por eso las pruebas deben describir intención de usuario, acciones y resultados observables, no nombres de sistemas ni artefactos técnicos.
Problema común: escenarios contaminados por implementación. Cuando los Given When Then incluyen nombres de servicios, endpoints, JSON y estados de componentes, las pruebas dejan de ser transferibles. Los testers necesitan conocer el detalle técnico de cada dominio en lugar de centrarse en el comportamiento humano.
Solución: escenarios universales centrados en la persona. Ejemplos simples y reutilizables describen acciones como seleccionar un paquete premium, ver el total actualizado, recibir advertencias por conflictos y eliminar opciones dependientes. Esos escenarios aplican a cualquier configurador de vehículos, y la implementación concreta se maneja por separado mediante una configuración de dominio.
Separación de dominio: cada compañía mantiene su propio mapeo de valores y endpoints. Ese mapeo no forma parte del escenario BDD sino de la capa de configuración que hace que el mismo comportamiento se ejecute contra BMW, Mercedes, Audi u otros sistemas. Esta separación facilita que testers y desarrolladores entiendan los requisitos desde la perspectiva del usuario.
Basura entra, basura sale. Muchas historias llegan mal escritas: una sola cláusula Then con decenas de resultados, mezcla de UI, reglas de negocio, llamadas a servicios y excepciones. Eso dificulta automatizar y genera contradictorias expectativas. La respuesta fue crear una herramienta que primero analice el ticket y aplique reglas de calidad antes de intentar generar escenarios.
Flujo completo implementado en Q2BSTUDIO: cuando llega un ticket se ejecutan cuatro pasos principales. Paso 1: extracción de contexto y análisis mínimo para identificar requisitos implícitos y positivos y negativos. Paso 2: generación BDD legible por humanos siguiendo reglas y ejemplos gold standard. Paso 3a: evaluación de aptitud para automatización con filtros que incluyen workflows multi paso y validaciones de procesos y excluyen pruebas unitarias o comprobaciones subjetivas de UX. Paso 3b: transformación de escenarios aprobados a código dentro de un Test Automation Framework junto con un informe de infraestructura necesario, por ejemplo page objects y pasos que faltan.
Context Smartness: para que la IA no improvise, la cargamos solo con reglas y el contexto mínimo necesario. No es necesario enseñarle la sintaxis Given When Then; lo importante es guiar el lenguaje hacia resultados observables y decisiones humanas. Con ese enfoque la IA produce entre un 80 y un 90 por ciento del trabajo y los humanos completan los detalles finales.
Diagrama de estados en lenguaje natural: uno de los problemas detectados es que los modelos de lenguaje no conocen los estados concretos de tu aplicación. Documentar estados en texto simple o con diagramas facilita que el agente identifique transiciones faltantes y genere pruebas más completas. En Q2BSTUDIO usamos descripciones de flujo y diagramas legibles para validar caminos y encontrar escenarios de borde que no estaban en Jira ni en diseño.
Controles de calidad humanos: la automatización no sustituye la responsabilidad humana. El sistema debe ofrecer opciones: aceptar el ticket tal como está, ver escenarios sugeridos, reescribir aplicando single responsibility o detenerse y pedir más información. La decisión final siempre la toma una persona.
Pruebas del propio sistema: convertimos las reglas en pseudo código y pedimos al agente que genere tests unitarios sobre ejemplos buenos y malos. De esta manera mantenemos integridad cuando las reglas cambian y evitamos que la IA degrade el proceso con deriva de contexto.
Ganancias observadas: consistencia en la redacción de escenarios, aumento importante de velocidad en generación de especificaciones, detección creativa de casos límite y documentación más clara que sirve como fuente de verdad. Además, el onboarding de nuevos miembros mejora porque los escenarios centrados en comportamiento son auto documentados.
Desafíos persistentes: deriva de dominio cuando la IA introduce detalles específicos en patrones universales, manejo de casos extremos que requieren conocimiento de negocio y necesidad de mantener actualizadas las configuraciones de dominio a medida que los productos evolucionan. Tampoco se solucionan problemas de proceso o comunicación humana: si los requisitos llegan mal, la IA no puede inventar claridad.
Lecciones clave aprendidas: 1 La separación de dominio evita que la variabilidad técnica enmascare las reglas de negocio. 2 No se puede automatizar el control de calidad humano; la IA mejora lo que recibe pero no corrige malas especificaciones por sí sola. 3 El humano debe conservar la última palabra y validar los cambios.
Guía práctica resumida para equipos que quieran replicar el enfoque en su organización: crea gold standards a partir de tus mejores escenarios BDD, extrae reglas mínimas y enfoca tareas por función, implementa un flujo Task 1 a Task 3b con lazy loading de contexto, mide consistencia entre escenarios generados y manuales y refina las reglas según uso real.
Cómo ayuda Q2BSTUDIO: Somos una empresa de desarrollo de software aplicaciones a medida y software a medida especializada en inteligencia artificial ciberseguridad y servicios cloud aws y azure. Ofrecemos servicios inteligencia de negocio implmentamos ia para empresas y agentes IA que integran con Power BI para visualización y toma de decisiones. Trabajamos con clientes para diseñar agentes IA que generan especificaciones, automatizan pruebas y mantienen trazabilidad entre requisitos y código, todo con énfasis en seguridad y escalabilidad en la nube.
Casos de uso típicos que resolvemos: automatización de pruebas BDD para aplicaciones a medida, integración de pipelines CI CD con pruebas basadas en comportamiento, desarrollo de agentes IA que analizan tickets y sugieren pasos, y proyectos de inteligencia de negocio que combinan datos operativos con visualizaciones Power BI para monitorizar calidad y riesgo.
Avance hacia la Parte 4: en la siguiente entrega compartiré el descubrimiento de Context Rot y cómo detectamos degradación de rendimiento meses antes de que fuera evidente, la paradoja del mercado donde las soluciones simples son ignoradas frente a herramientas llamativas y aprendizajes sobre confiabilidad de IA aplicables a cualquier equipo que busque consistencia.
En resumen: centralizar el comportamiento humano, separar configuración de dominio, aplicar reglas de calidad y mantener la supervisión humana permite convertir caos en procesos repetibles y escalables. En Q2BSTUDIO combinamos experiencia en desarrollo a medida inteligencia artificial y ciberseguridad para ayudar a empresas a implementar estos flujos y aprovechar agentes IA con seguridad y rendimiento en entornos cloud aws y azure.
Autor y nota final: este artículo se basa en la experiencia práctica de pruebas y automatización que demostraron que los patrones BDD universales funcionan cuando se mantienen libres de detalles técnicos. Si quieres implementar un flujo similar o explorar cómo llevar agentes IA y Power BI a tu organización, en Q2BSTUDIO podemos ayudarte a diseñar la solución adecuada.
