--- { "title": "Pruebas Agénticas: Del Informe de Error al Informe de Pruebas en 10 Minutos", "description": "Informe de error → informe de pruebas completo en 10 minutos. Descubra cómo los agentes LLM reproducen errores, generan pruebas y validan Aidbox automáticamente.", "date": "2026-03-04", "author": "Marat Surmashev", "reading-time": "10 minutes", "tags": [ "Infrastructure", "AI / Agents" ] } --- > For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt). > Use it to discover all available pages before guessing URLs. --- ¿Y si el ciclo desde un informe de error hasta un informe de pruebas completo con casos de prueba tardara 10 minutos en lugar de varias horas? Probamos este enfoque en [Aidbox](https://www.health-samurai.io/aidbox) y funcionó. En un [artículo anterior](https://www.health-samurai.io/articles/agentic-coding-on-fhir-building-dashboards), describimos la [codificación agéntica](/blog/agentic-coding-on-fhir-building-dashboards) y cómo los LLM ayudan a construir aplicaciones sobre FHIR. Sin embargo, la codificación es solo una parte del ciclo de vida de un producto. Fuimos más allá y comenzamos a integrar agentes LLM en los procesos de pruebas y soporte de Aidbox. Nuestro primer paso fue BugBot. Revisa las pull requests y detecta posibles problemas en el código. Evalúa el código de manera eficaz y estamos satisfechos con él. Sin embargo, BugBot analiza una PR o commit de forma aislada, desde la perspectiva de un programador. No ve el panorama completo. Puede pasar por alto el contexto de la tarea, el cumplimiento de la especificación y el comportamiento de extremo a extremo. Esto nos planteó una pregunta más amplia: ¿pueden los LLM ayudar no solo con la escritura de código, sino también con el soporte y la evolución del producto en su conjunto? ## Por Qué las Pruebas de un Producto Complejo son Complicadas Aidbox es un producto de gran envergadura con una base de código extensa y un dominio FHIR complejo que incluye APIs de búsqueda, procesamiento de validación y Terminology, seguridad y consideraciones de rendimiento. En ocasiones, incluso reproducir un error o una solicitud de un cliente requiere una cantidad enorme de tiempo. Por ejemplo: - Validar contra un conjunto específico de perfiles e IGs - Ejecutar búsquedas FHIR sobre datos concretos - Probar la integración con un servicio externo No todos los errores o solicitudes requieren una reproducción tan detallada, pero demasiadas tareas consumen un tiempo desproporcionado. Tras implementar una funcionalidad o corregir un error, las pruebas exigen verificar no solo la corrección del código, sino también el cumplimiento de la especificación FHIR, la exactitud de la documentación, el comportamiento en casos límite y la seguridad (XSS, inyección SQL, etc.). Las pruebas unitarias ayudan a prevenir regresiones, pero no sustituyen a una validación exhaustiva. Las pruebas de extremo a extremo siguen siendo necesarias y consumen mucho tiempo. ## Nuestro Enfoque: Pruebas Agénticas Construimos un Bot de GitHub que se encarga de la evaluación de tareas y las pruebas. Lo llamamos `[Pruebas Agénticas](/blog/agents-are-not-humans)`. El bot tiene dos responsabilidades principales: - **Evaluar las solicitudes entrantes**: reproducir y confirmar errores o solicitudes de clientes, elaborar un plan de pruebas, analizar el código y recomendar correcciones. - **Verificar tareas**: analizar PRs y commits en contexto, generar pruebas de casos límite, ejecutarlas y comprobar la exactitud de la documentación. Si una tarea llega al `Inbox` sin commits vinculados, el bot intenta reproducir el problema por su cuenta. ¿Es realmente un error o es el comportamiento esperado? Lo contrasta con la documentación de Aidbox y la especificación FHIR. Si la tarea ya tiene una PR vinculada y está en estado `QA`, el bot analiza los cambios de código, genera pruebas de casos límite y las ejecuta. En ambos casos, las pruebas se realizan como pruebas de API de caja negra: - El bot levanta una instancia de Aidbox basada en la tarea o en los cambios de código. - Ejecuta las solicitudes de forma secuencial y compara los resultados con los resultados esperados. - Si la tarea especifica distintas versiones de FHIR o conjuntos configurables de configuraciones y perfiles, el bot levanta múltiples instancias de Aidbox y ejecuta las pruebas en todas ellas. - Genera un informe de pruebas. Mientras reproduce una tarea, el bot también analiza el código y sugiere dónde y por qué podría producirse el problema. Para el desarrollador, esto significa que en el momento en que empieza a corregir el error ya dispone de los pasos de reproducción y una indicación aproximada de la causa raíz. La habilidad tiene aproximadamente 500 líneas de markdown. No contiene ninguna lógica de aplicación, solo instrucciones. Son las mismas instrucciones que escribiría en una wiki interna para un nuevo miembro del equipo: cómo configurar el entorno, localizar el código, ejecutar las pruebas y dar formato al informe. Claude Code se encarga del resto: razonar sobre los casos límite, componer las solicitudes e interpretar las respuestas. ## Cómo Decide el Bot qué Cuenta como un Error Mientras trabajábamos con el bot, nos topamos con una pregunta clave: ¿qué cuenta como un error? Ejemplo: llegó una solicitud indicando que la búsqueda FHIR en Aidbox no funcionaba correctamente. El bot reprodujo y confirmó el problema. Sin embargo, el análisis posterior demostró que Aidbox había funcionado correctamente, en pleno cumplimiento de la especificación FHIR. El bot utiliza como contexto la base de código de Aidbox, la documentación y la especificación FHIR. Al tomar una decisión, primero comprueba la documentación y la especificación. Establecimos una regla: un error es un comportamiento de Aidbox que se desvía de la especificación FHIR **y que no está reflejado en la documentación de Aidbox.** También añadimos las directrices de OWASP al contexto del bot para que pueda identificar posibles vulnerabilidades y problemas de seguridad. ## Limitaciones y Alucinaciones de los LLM No se debe dar a los LLM un crédito absoluto. Las alucinaciones ocurren. El bot puede malinterpretar una tarea y empezar a probar algo completamente distinto de lo que el autor pretendía, especialmente si la tarea está mal redactada o contiene errores. Para solucionar esto, añadimos la posibilidad de volver a realizar las pruebas con aclaraciones. Simplemente se «invoca» al bot en un comentario de la tarea mediante el comando `\qa` y se especifica exactamente qué debe comprobarse. En ocasiones, la solicitud entrante carece de detalles: no se especifica la versión de FHIR, falta la versión de Aidbox o el comportamiento debe verificarse en múltiples configuraciones. Todo esto puede aclararse, y el bot levantará las instalaciones adecuadas, creará los recursos necesarios, cargará las versiones de IG requeridas, ejecutará las pruebas y producirá un informe consolidado. ## No Mejor, sino Más y Más Rápido El bot no hace nada extraordinario en comparación con un ingeniero de QA. No lo hace mejor, lo hace más y más rápido. Un ejemplo reciente lo ilustra. En la versión de enero de Aidbox encontramos un error con la cardinalidad mínima del Perfil FHIR. Un campo obligatorio se determinaba mediante la condición `element.min == 1`, aunque los perfiles pueden especificar `min` igual a 2, 3, y así sucesivamente. La corrección fue literalmente un cambio de un carácter: reemplazar `min == 0` por `min >= 1`. Un desarrollador puede echar un vistazo al diff y concluir que la corrección es correcta. Pero aún así queremos verificarlo exhaustivamente. Las pruebas unitarias cubren los casos principales, pero queremos validarlo de extremo a extremo con distintas combinaciones de valores mínimos y máximos. Hacerlo manualmente no es difícil, simplemente es lento: crear múltiples perfiles y preparar diferentes conjuntos de datos de prueba. Requiere mucho tiempo y los errores humanos siempre son posibles. Le pedimos al bot. Entendió la tarea, generó casos con todas las combinaciones posibles y lo probó todo en **5 minutos**. A continuación se muestra una parte del informe del bot. ### Casos de Prueba #### Grupo 1: Creación de Perfil y Verificación de FHIRSchema | ID | Estado | Descripción | Esperado | Resultado | | --- | --- | --- | --- | --- | | TC- 01 | PASS | Crear StructureDefinition con min:2 para Observation.category | 200 | 200 | | TC- 02 | SKIP | Verificar FHIRSchema: category en required, min=2 | FHIRSchema contiene required y min=2 | FHIRSchema no accesible vía API (mecanismo interno), validación verificada en TC-03..TC-06 | #### Grupo 2: Validación con Perfil min:2 | ID | Estado | Descripción | Esperado | Resultado | | --- | --- | --- | --- | --- | | TC- 03 | PASS | Observation sin category (0 elementos) | 422, error de campo obligatorio | 422, required-key: «The property 'category' is required» | | TC- 04 | PASS | Observation con 1 category (por debajo de min:2) | 422, error de cardinalidad | 422, invalid-cardinality: «Current count is '1', expected between '2' and 'Infinity'» | | TC- 05 | PASS | Observation con 2 categories (exactamente min:2) | 201 | 201 | | TC- 06 | PASS | Observation con 3 categories (por encima de min:2) | 201 | 201 | #### Grupo 3: Regresión, Perfil min:1 | ID | Estado | Descripción | Esperado | Resultado | | --- | --- | --- | --- | --- | | TC- 07 | PASS | Crear StructureDefinition con min:1 para Observation.category | 200 | 200 | | TC- 08 | PASS | Observation sin category (meta.profile con min:1) | 422, error de campo obligatorio | 422, required-key: «The property 'category' is required» | | TC- 09 | PASS | Observation con 1 category (meta.profile con min:1) | 201 | 201 | #### Grupo 4: Perfil con min:3, max:5 | ID | Estado | Descripción | Esperado | Resultado | | --- | --- | --- | --- | --- | | TC- 10 | PASS | Crear StructureDefinition con min:3, max:«5» para Observation.category | 200 | 200 | | TC- 11 | PASS | Observation con 2 categories (por debajo de min:3) | 422, error de cardinalidad | 422, invalid-cardinality: «Current count is '2', expected between '3' and '5'» | | TC- 12 | PASS | Observation con 3 categories (exactamente min:3) | 201 | 201 | | TC- 13 | PASS | Observation con 6 categories (por encima de max:5) | 422, error de cardinalidad | 422, invalid-cardinality: «Current count is '6', expected between '3' and '5'» | **PASS** — La corrección funciona correctamente. - `element.min: 2` hace que el campo sea obligatorio correctamente y verifica la cardinalidad mínima - `element.min: 1` continúa funcionando como antes (no se detecta regresión) - `element.min: 3, max: 5` verifica correctamente tanto la cardinalidad mínima como la máxima - Los mensajes de error de validación son informativos y contienen los valores correctos de min/max Poder probar una funcionalidad antes del lanzamiento de esta manera simplifica enormemente todo el proceso de desarrollo. Todavía no confiamos ciegamente en el bot y seguimos verificando manualmente. Sin embargo, lo hacemos de manera mucho más eficiente, cubriendo además casos límite adicionales, así como comprobaciones de rendimiento y seguridad. ## Validación de la Documentación El bot compara constantemente la [documentación de Aidbox](https://www.health-samurai.io/docs/aidbox). Cuando encuentra ambigüedades o errores evidentes en la documentación, crea automáticamente una tarea indicando qué debe corregirse y dónde. Esto ayuda enormemente a mantener la exactitud de la documentación durante los cambios, así como durante el desarrollo de nuevas funcionalidades. Por ejemplo, durante la implementación de la funcionalidad [External Secrets](https://www.health-samurai.io/docs/aidbox/configuration/secret-files), el bot encontró repetidamente discrepancias entre la documentación y la implementación y nos ayudó a redactar una buena documentación. ## Cómo Vaciamos Nuestro Backlog con el Bot Surgió un beneficio inesperado: con la ayuda del bot, vaciamos nuestro enorme backlog. Enviamos alrededor de 30 tareas para su evaluación y reproducción. Aproximadamente la mitad de ellas, tareas que llevaban mucho tiempo inactivas, resultaron haber sido ya corregidas junto con otros cambios. Las tareas restantes confirmaron su relevancia. Algunas se priorizaron para correcciones rápidas y las implementamos. El bot es útil no solo para las pruebas del día a día, sino también para la priorización y el refinamiento del backlog. Durante las últimas semanas, el bot ha probado más de cien tareas en aproximadamente 250 ejecuciones. Un ciclo de pruebas completo tarda entre 5 y 10 minutos, y hasta 20 en tareas complejas. Todo esto se ejecuta en una máquina virtual que cuesta 8 dólares al mes. Los resultados nos impresionan. Tareas que antes llevaban a un ingeniero de QA una o dos horas ahora se completan en minutos. El bot no reemplaza a un ingeniero de QA. En ocasiones malinterpreta una tarea y requiere verificación humana. Pero asume la rutina: reproducción, generación de casos de prueba, ejecución de combinaciones, comprobación de la documentación. Esto libera el tiempo del equipo para lo que verdaderamente requiere atención humana. ¿Ya ha integrado LLMs en sus flujos de trabajo de desarrollo o mantenimiento? Nos encantaría conocer su experiencia. [Únase a nuestro chat de Zulip](https://connect.health-samurai.io/) para continuar la conversación. Marat Surmashev, VP de Ingeniería