¿En qué consistió el acompañamiento de Grupo Esfera con este equipo de salud?

Grupo Esfera diseñó una intervención en dos niveles: consultoría estratégica para el equipo de Certificaciones de calidad, y mentoría directa a dos equipos piloto, con capacitaciones, sesiones de implementación grupales y seguimientos quincenales.

¿Qué tipos de pruebas se implementaron?

Se incorporaron 7 tipos de prueba distintos: pruebas unitarias y de integración, pruebas de homologación para servicios externos (con una jerarquía de herencia para homologar turnos con múltiples proveedores), y reutilización de monitoreo como smoke tests en despliegues.

¿Cuánto duró el trabajo y qué resultados concretos dejó?

El trabajo conjunto duró 6 meses, en los que se dictaron 13 capacitaciones y se impulsaron 14 mejoras concretas, con las automatizaciones ya integradas al pipeline de CI/CD.

<- Volver

>>>

Soluciones conversacionales

Evolución del desarrollo y testing de bots conversacionales con IA Generativa

De pruebas manuales por WhatsApp a testing automatizado y LLM-as-a-judge para validar respuestas generativas.

Grupo Esfera transformó de punta a punta cómo el equipo del cliente construye y prueba sus bots conversacionales, pasando de una validación 100% manual a un pipeline de integración continua con una metodología propia para testear respuestas de IA Generativa.

QUIERO AGENDAR UNA REUNION

VER MÁS CASOS

Resumen

De bots determinísticos a asistentes conversacionales con IA Generativa

Grupo Esfera transformó, de punta a punta, la forma en la que uno de los equipos del cliente construye y prueba bots conversacionales de WhatsApp. Partiendo de un esquema sin ninguna prueba automatizada —todo se validaba a mano interactuando con WhatsApp— se construyó progresivamente un framework de testing propio basado en Gherkin, integración y entrega continua. Cuando los bots empezaron a apoyarse cada vez más en IA Generativa (hasta el 90% de la lógica en algunos casos), Esfera diseñó una metodología de testing para validar automáticamente respuestas no determinísticas: la técnica LLM-as-a-judge, sumada a una arquitectura donde las mismas reglas de negocio que alimentan las pruebas generan directamente el prompt del bot.

Ficha técnica

INDUSTRIA

Soluciones conversacionales

SERVICIO

Coaching Técnico (evolución de equipos, prácticas y procesos) + Desarrollo de soluciones con IA Generativa

EQUIPO

3 profesionales (1 arquitecto + 2 desarrolladores full stack)

METODOLOGÍA

Scrum + eXtreme Programming (XP), Trunk-Based Development, Feature Toggles, Continuous Integration & Continuous Delivery (CI/CD), Slicing, Visual Story Maps, Descubrimiento Evolutivo, Arquitectura Emergente

CALIDAD

Test-First (Gherkin/Cucumber), pruebas unitarias, pruebas exploratorias, Allure Reports, LLM-as-a-Judge, mocking (Mockoon)

STACK

JavaScript, .NET Core, C#, GitHub Actions, Vector Store, OpenAI API (Responses API / Chat Completions API)

Desafío

El equipo del cliente construye bots de WhatsApp (conectados a Meta) para múltiples clientes finales, cada uno con su propia lógica de negocio, sobre una plataforma interna con más de 50 bots conviviendo en un único repositorio.

1

Ausencia de pruebas automatizadas

No existían pruebas unitarias ni de integración sobre el comportamiento del bot. Toda validación se hacía manualmente, desplegando el bot a un ambiente de prueba desde la máquina local del desarrollador e interactuando a mano por WhatsApp.

2

Framework de testing abandonado

El equipo que provee la librería interna del bot había construido, tiempo atrás, un framework de pruebas funcionales basado en Gherkin y Cucumber, pero ningún equipo lo usaba: escribir el glue code que conectara cada paso de la prueba con una acción real del bot requería un conocimiento tan profundo de la plataforma que resultaba impráctico.

3

Entrega desordenada y sin trazabilidad

La gestión de ramas mostraba un antipatrón de branches de larga vida y el pipeline de CI eran en realidad GitHub Actions que no garantizaban nunca un build saludable. Muchas veces no había forma de saber con certeza qué versión de un bot estaba corriendo en el ambiente de release candidate.

4

Especificación rígida y desconectada del uso real

El flujo de un bot se acordaba con el cliente como un diagrama de flujo cerrado, se entregaba y no se volvía a tocar. Sin refinamiento continuo, era común que un cliente diera de baja un bot a los 6 meses porque nadie lo usaba.

5

La IA generativa multiplicó la complejidad de testear

Al incorporar módulos generativos —en algunos bots, hasta el 90% del comportamiento depende de un modelo de lenguaje— dejó de alcanzar con comparar una respuesta exacta. Cada ejecución podía dar una respuesta distinta, válida de maneras distintas, lo que hacía inviable validar el comportamiento con aserciones tradicionales.

Solución

Testing evolutivo e IA Generativa

Aplicando el Camino Esfera, Grupo Esfera conformó un equipo que trabajó bajo la premisa de que la calidad es el motor de la velocidad, no una barrera: entregar rápido no significaba escribir código rápido, sino llegar rápido y con confianza al ambiente productivo. La transformación fue progresiva y se apoyó en tácticas concretas sobre tres frentes: testing, entrega e IA Generativa.

Ver más sobre el Camino Esfera

Testing — Módulos y pruebas unitarias

Lógica del bot, aislada y testeable

Separamos el código del bot de la librería propietaria del cliente en módulos independientes, cubiertos con pruebas unitarias.

Testing — Especificación por ejemplos

Gherkin en vivo, sin depender de WhatsApp

Integración con OpenAI, Vector Stores (RAG) y arquitecturas multi-agente, con control de costos por conversación.

Entrega — Integración continua

De ramas eternas a un pipeline por bot

Migramos a Trunk-Based Development y construimos desde cero un pipeline que compila y testea cada bot afectado por un cambio.

Entrega — Despliegue continuo

De la máquina local a producción con un clic

Cada cambio se despliega solo a release candidate, y pasa a producción con una aprobación trazable de 15 minutos.

IA Generativa — Diseño de prompts

Menos reglas, más control

Descubrimos que sobrecargar el prompt lo hacía menos predecible: partimos del mínimo de reglas posible y sumamos restricciones solo cuando hacía falta.

IA Generativa — Testing no determinístico

Un juez de IA para respuestas de IA

Tradujimos las expectativas de negocio en aserciones generativas evaluadas por un segundo modelo (LLM-as-a-judge), con evidencia completa en cada corrida.

IA Generativa — Reglas y prompt

Las reglas que se prueban son las que se cumplen

Cada regla de negocio genera directamente el system prompt del bot, eliminando el desvío entre lo que se testea y lo que se le indica al modelo.

Resultados

Impacto medible en el negocio

ANTES Y DESPUÉS DE TRABAJAR CON GRUPO ESFERA

Indicador	Estado anterior	Con Grupo Esfera
Cobertura de pruebas	Cero pruebas automatizadas; validación 100% manual interactuando por WhatsApp	Suite de pruebas unitarias, exploratorias y de integración que corre automáticamente en cada cambio
Flujo de entrega	Despliegues manuales desde la máquina local, sin certeza de qué versión estaba en cada ambiente	Modelo de Continuous Delivery (CD) con Trunk-Based Development, despliegues automáticos y Feature Toggles.
Validación de IA Generativa	Sin forma de validar respuestas no determinísticas más allá de probarlas a mano	Metodología LLM-as-a-judge integrada al pipeline, con evidencia completa de prompts, respuestas y veredictos
Consistencia entre reglas y prompt	Reglas de negocio documentadas aparte del prompt, con desvíos frecuentes entre ambos	Reglas de negocio y system prompt generados desde una única fuente de verdad
Capacidad conversacional	Bots con flujos rígidos y una sola lógica de respuesta	Arquitectura multi-agente, memoria persistente y búsqueda en base de conocimiento propia (RAG)