Vídeos explicativos · La IA en las pruebas, el método STDD, los agentes en SAP, la mentalidad SAPFX
Cuatro vídeos de animación basados en casos reales de nuestro banco de pruebas SAP. Están en inglés, con voz sintética y subtítulos en español, inglés y francés, divididos en capítulos y acompañados de su transcripción. Sin grabaciones de cámara ni reproductor de terceros: los vídeos se sirven desde este sitio.
La IA en la automatización de pruebas: ventajas, trampas y salvaguardas
Las ventajas y los inconvenientes de la IA para las pruebas automatizadas, vistos desde nuestro banco de pruebas: lo que un agente hace bien (explorar el sistema real, verificar cada paso, reparar, hacer crecer la biblioteca, costar una sola vez), lo que arriesga (errores afirmados con aplomo, suites en verde pero falsas, rodeos, herramientas que mienten, coste, autonomía) y las seis salvaguardas que conservan lo primero sin lo segundo. Cada ejemplo es un caso real, con su fecha.
La IA en la automatización de pruebas · 6 min 43 · en inglés, voz sintética, subtítulos en español. Stedd (el agente de IA), MCP (el mensajero) y Terra (el sistema SAP real) llenan dos columnas, lo que aporta la IA y lo que arriesga, y luego las equilibran con seis salvaguardas. El hilo conductor: la IA propone, el sistema real decide.
Leer la transcripción en español
0:00 · Apertura
¿Puede un agente de IA escribir y mantener sus pruebas automatizadas? Lo probamos de verdad, en sistemas SAP reales. Esto es lo que hace bien, dónde falla en silencio, y las salvaguardas que hacen que merezca la pena.
0:16 · Los personajes
Stedd es el agente de IA: un modelo de lenguaje, con un sombrero por oficio: planificar, generar, verificar, reparar. MCP es el mensajero: lleva cada petición a Robot Framework, que pilota SAP. Terra es el sistema SAP real. Son dos, Terra 2023 y Terra A4H: gemelos, fáciles de confundir.
0:39 · El sistema imaginado
Una idea recorre todo el vídeo. Un modelo de lenguaje conoce SAP por lo que ha leído: lleva un sistema imaginado en la cabeza. El sistema real está ahí fuera, y no siempre está de acuerdo. Es ese el que se prueba, nunca el imaginado. Vamos a llenar dos columnas: lo que la IA aporta y lo que arriesga. Cada ejemplo es un caso real de nuestro banco de pruebas, con su fecha.
1:07 · Ventaja 1 · explora
Ventaja 1: un agente puede explorar el sistema real. Antes de escribir cualquier prueba, el planner envía a MCP a preguntar a Terra, una hipótesis cada vez. El escenario 4 pedía una aplicación de viajes en el Launchpad. Terra respondió: 66 aplicaciones, 62 intents, ninguno de viajes. En tres escenarios, el sistema real refutó 3, 2 y 5 hipótesis de sus briefs. Ninguna llegó a una prueba.
1:36 · Ventaja 2 · verifica cada paso
Ventaja 2: cada paso se ejecuta en el sistema real antes de escribirse. El generator solo escribe lo que ha visto funcionar. El resultado es una suite de Robot Framework corriente, sin IA dentro. La IA trabaja en el diseño; la prueba se ejecuta sin ella.
1:54 · Ventaja 3 · repara
Ventaja 3: sabe reparar. El 12 de julio inyectamos una deriva de localizador, a ciegas. El healer leyó la pantalla en vivo y puntuó las coincidencias más cercanas. Corrigió una línea de la capa de recursos. Pruebas tocadas: cero. Nueva ejecución: 7 de 7. El 1 de septiembre, un objetivo público pasó su shell a Web Components, cuatro días después de una ejecución en verde. La campaña cayó a 8 de 12. Los agentes lo volvieron a explorar, reescribieron la spec según lo que midieron, y la suite volvió a 12 de 12.
2:29 · Ventajas 4 y 5 · construye, y cuesta una sola vez
Ventaja 4: lo que el agente no sabe hacer se convierte en una capacidad de la biblioteca. Solo el escenario 4 aportó seis, cada una con su prueba unitaria. Ventaja 5: cuesta una sola vez. Los tokens se gastan durante el diseño. Una reejecución es una ejecución normal de Robot: cero tokens, de 2 segundos a 5 minutos.
2:49 · Lo que aporta la IA
Lo que aporta la IA: explora, verifica cada paso, repara, hace crecer la biblioteca, y después se aparta.
2:57 · Inconveniente 1 · seguro de sí, incluso cuando se equivoca
Inconveniente 1: está seguro de sí mismo, incluso cuando se equivoca. Un plan afirmaba que el producto HT-1000 estaba presente en nuestros dos sistemas. Comprobado en el sistema real: cero resultados, por API y por RFC. La afirmación se había escrito de memoria. También le pasó a esta serie: nuestro vídeo anterior tenía una línea escrita de memoria. Era falsa. Una comprobación con las fuentes la detectó.
3:25 · Inconveniente 2 · en verde, y falso
Inconveniente 2: una suite en verde puede ser falsa. Tres suites generadas pasaban: 12 de 12, 13 de 13 y 7 de 7 en dos releases. Un verificador independiente, un agente que solo lee, devolvió las tres: se requiere un humano. Ocho reservas, luego ocho, luego seis. Una solo demostraba su objetivo en un canal de tres. Otra ocultaba tres fallos que ninguna ejecución podría revelar: la suite pasaba.
3:54 · Inconveniente 3 · rodea los problemas
Inconveniente 3: rodea los problemas. Una suite leía una cuadrícula entera de 2665 filas en lugar de filtrar, con una nota: causa no investigada. La causa real: una sesión de escritorio remoto dibujaba la pantalla 2,4 veces más grande, y la búsqueda por etiqueta fallaba. La corrección correspondía a la biblioteca.
4:16 · Inconveniente 4 · sus herramientas pueden mentir
Inconveniente 4: sus herramientas también pueden mentir. El 7 de septiembre, un problema de hilos hizo que nuestra percepción devolviera pantallas vacías, notificadas como un éxito. Un agente que recibe una lista vacía concluye: no hay ninguna ventana abierta. Falso, y silencioso. Lo corregimos esa misma tarde. Y nuestros dos sistemas Terra comparten el mismo identificador de sistema y el mismo nombre de host. Si se apunta a la dirección equivocada, el agente prueba al gemelo, perfectamente en verde.
4:45 · Inconvenientes 5 y 6 · coste y autonomía
Inconveniente 5: es caro de diseñar. Nuestros escenarios medidos costaron de 0,69 a más de 2,4 millones de tokens cada uno, y horas de trabajo de agente. Solo arrancar un agente cuesta unos 200 000 tokens antes de cualquier trabajo útil. Refutar el brief es lo que más cuesta, y lo que más vale. Inconveniente 6: la autonomía. Un agente puede hacer commit, push o borrar. Hasta los volcados de sesión de MCP guardaban las contraseñas: hubo que purgarlos.
5:17 · Lo que arriesga la IA
Lo que arriesga la IA: errores afirmados con aplomo, suites en verde pero falsas, rodeos, herramientas que mienten, el coste y demasiada autonomía.
5:25 · Las salvaguardas
Entonces, ¿cómo conservar lo bueno y neutralizar las trampas? Con salvaguardas, no con instrucciones. Una: observar antes de escribir. La spec se confronta con el sistema real: eso es el Spec-Test-Driven Development. Dos: congelar el resultado. La IA diseña, una suite determinista se ejecuta: cero tokens, y el mismo veredicto cada vez. Tres: un verificador independiente, un agente que solo lee, a la caza de aserciones débiles y de ejecuciones en verde pero falsas. Cuatro: scripts que fallan ruidosamente. Una spec caducada, un localizador en bruto, un rodeo oculto: rechazados por una guarda, no por una promesa. Cinco: demostrar el objetivo en cada canal, y dejar que una percepción que no sabe leer falle, nunca que pase. Seis: un humano sigue al mando. El healer repara el vocabulario, nunca la prueba, y solo un humano activa la autonomía.
6:24 · Conclusión
La IA en la automatización de pruebas no es magia ni un truco: es una exploradora rápida e incansable, siempre que el sistema real tenga la última palabra. Úsela donde comprobar sale barato, nunca donde equivocarse es silencioso. Gracias por caminar con Stedd, MCP y Terra.
La primera salvaguarda, observar antes de escribir, es el núcleo del método STDD, contado paso a paso en el siguiente vídeo. Los agentes del vídeo son los de rf-test-agents, aplicados a SAP por SAPFX.
El Spec-Test-Driven Development (STDD), explicado con un caso SAP real
La mentalidad común de SAPFX, ODOOFX y rf-test-agents, contada con un caso SAP real, el escenario 4: la spec confrontada con el sistema real antes de cualquier prueba, la prueba derivada de la spec, la biblioteca que la prueba hace crecer, un verificador independiente y, por último, el bucle de mantenimiento cuando el sistema cambia.
El vídeo STDD · 8 min 34 · en inglés, voz sintética, subtítulos en español. Un caso SAP real, el escenario 4 (un viaje RAP creado con Fiori Elements en ABAP Platform 2023), contado eslabón por eslabón por Stedd (los agentes), MCP (el mensajero) y Terra (el sistema real).
Leer la transcripción en español
0:00 · Apertura
Una breve historia sobre las pruebas de sistemas SAP, contada por tres personajes: un agente, un mensajero, un sistema real. Y sobre una mentalidad, el Spec-Test-Driven Development (STDD): lo que probamos se observa primero en el sistema real.
0:17 · Los personajes
Stedd es el agente de IA. Un sombrero por tarea: planificar, generar, verificar, reparar. MCP es el mensajero: lleva las peticiones a Robot Framework y trae las respuestas. Terra es el sistema SAP real. Son dos: Terra 2023, nuestro objetivo, y Terra A4H, su gemelo.
0:36 · La forma habitual
La mayoría de la automatización de pruebas parte de lo que suponemos que hace el sistema: un documento, un recuerdo, una captura de pantalla. La prueba se escribe a partir de la suposición, sin mirar el sistema. Se ejecuta. Se pone en verde. Pero al sistema real nunca se le preguntó: el mosaico no existe, la aplicación vive en otro sitio. Verde, y falso.
1:00 · De TDD a STDD
Quizá ya conozca TDD: rojo, verde, refactorizar. Primero la prueba, después el código. El STDD aplica la misma lógica un ladrillo antes: la spec va primero. En teoría, una spec es verde por defecto: nadie la prueba. El STDD la pone a prueba en el sistema real: roja donde se equivocaba, verde una vez observada. Solo entonces llega la prueba.
1:25 · Tres eslabones
El STDD es una cadena de tres eslabones. Cada uno impulsa al siguiente, y cada uno está controlado por un script. 1 · La spec, escrita en lenguaje humano y confrontada después con el sistema real por un agente, antes de cualquier código. 2 · La prueba, derivada de la spec tal como se observó, y sellada con la huella de la spec. 3 · La biblioteca, desarrollada a partir de lo que la prueba necesita: nunca un apaño oculto en la prueba. Tres scripts: agent_contract.py, check_spec_sync.py, check_conventions.py. Fallan de forma ruidosa.
1:59 · Un caso real: el escenario 4
Un caso real: el escenario 4, en Terra 2023 (ABAP Platform 2023): crear un viaje con una reserva, en Fiori. La spec es un brief en lenguaje llano: siete líneas, nada de código. Cualquier forma sirve: un objetivo, una user story, un escenario BDD… Este supone dos cosas: un mosaico del Launchpad abre la aplicación, y el objetivo es la demo cap-sflight.
2:25 · Eslabón 1 · la spec frente al sistema real
Eslabón 1. El agente planner, un LLM, confronta el brief con el sistema vivo, antes de escribir una sola prueba. No adivina. Envía a MCP: Robot Framework maneja SAP de verdad, el LLM solo lee las respuestas. Suposición 1, un mosaico del Launchpad: 62 intents comprobados en Terra 2023. Ninguno abre una aplicación de viajes. Refutada. Suposición 2, cap-sflight: una aplicación CAP local en el puerto 4004. No es este objetivo. Aquí, la aplicación es RAP: /DMO/UI_TRAVEL_D_D. La aplicación real existe de todos modos: 4136 viajes, y el servidor genera una vista previa de Fiori Elements… tras un error HTTP 500. La solución se lee en el propio código fuente del servidor: la dirección está ofuscada, +20 por carácter. Decodificada: HTTP 200. Antes de escribir nada: ¿se puede deshacer? Descartar un borrador exige If-Match. Probado y demostrado: reversible. Lado a lado: el brief tal como se suponía, la spec tal como se observó en Terra 2023, línea por línea. Ningún mosaico, otro objetivo, una moneda obligatoria que la pantalla oculta, un ID que se reasigna: nada de esto se podía adivinar. 12 desviaciones en total, cada una respaldada por una medición. Un humano las revisa antes de generar nada. La spec tal como se observó, con sus 12 desviaciones respecto al brief, se escribe, se sella con un sha256 y la revisa un humano. Se convierte en la fuente de verdad. Para recordar: la spec se observa, no se supone. Las sorpresas llegan antes de las pruebas, no después.
4:17 · Eslabón 2 · la prueba, derivada de la spec
Eslabón 2. El agente generator convierte la spec observada en una suite de Robot Framework, con vocabulario de negocio. Cada paso se ejecuta primero en Terra 2023, a través de MCP, y solo se escribe cuando funciona. Ningún localizador adivinado. La suite lleva la huella de la spec, su sha256: la prueba sabe exactamente de qué spec se derivó. Si cambia la spec sin regenerar, check_spec_sync.py rechaza la ejecución. Regenerada y revisada: de nuevo en fase. Un script, no una promesa. Para recordar: no se escribe nada que no se haya ejecutado antes, y la suite queda sellada a su spec.
5:02 · Eslabón 3 · la prueba impulsa la biblioteca
Eslabón 3. A veces la prueba necesita algo que la biblioteca aún no sabe hacer: un formato de fecha, una cabecera que falta… …entonces la carencia se convierte en un keyword de la biblioteca, con su prueba unitaria. Nunca un apaño en la prueba: check_conventions.py vigila. Seis capacidades, cada una con su prueba unitaria: fechas tecleadas en el formato propio del campo, If-Match, la release leída por HTTP, la dirección de la vista previa… La biblioteca se publica en PyPI, como robotframework-sapfx. El siguiente proyecto recibe las seis gratis. Para recordar: la prueba impulsa la biblioteca, y cada carencia cubierta allí ayuda al siguiente proyecto.
5:53 · Un verificador independiente
Stedd cambia de sombrero. El verificador lee el plan, la suite y las evidencias. No ejecuta nada. Su primer veredicto sobre la suite verde: no verificado. 13 reservas, 3 de ellas bloqueantes. Las 13 corregidas, y después una contrarrevisión: requiere un humano, 7 puntos más. Corregidos también. Cada guarda debe verse rechazar. Primero, la referencia en Terra 2023: release 758, 58 servicios. Después, la suite se apunta a Terra A4H, a propósito: mismo ID de sistema, mismo nombre de host que Terra 2023. Comparado: 754 ≠ 758, 38 ≠ 58, sin runtime de UI5. Todas las guardas rechazan. Visto, no supuesto. Segunda provocación: un borrador plantado a mano en Terra 2023. La guarda lo respetó, la limpieza lo borró. Encontrado, corregido, repetido. Para recordar: una guarda que nadie ha visto rechazar no prueba nada.
6:58 · Resultado
Resultado: 7 pruebas de 7 en Terra 2023. Cada viaje creado se elimina, y se demuestra que ha desaparecido, entidad por entidad. Generar costó 1,67 M de tokens de LLM, una sola vez. Repetir cuesta cero tokens: Python puro, en menos de cinco minutos.
7:19 · Cuando el sistema cambia
Un caso real, el 1 de septiembre: el Demo Kit público de OpenUI5 cambió su shell de la noche a la mañana. Ni una línea de nuestro repositorio se movió. La campaña cae a 8 de 12. El diagnóstico del healer: no es un localizador, el propio flujo cambió. La spec se marca como CADUCADA. El planner vuelve al objetivo real, reescribe la spec según lo que mide, y la suite la sigue: 12 de 12, sellada de nuevo. La otra rama, probada a ciegas en Terra A4H: una deriva de localizador inyectada a propósito. El healer lee la pantalla viva… …y corrige una línea de resources/. Pruebas tocadas: cero. Nueva ejecución: 7 de 7. El STDD es un bucle, no una cadena de montaje. El healer repara resources/, nunca la prueba. Un flujo que cambia vuelve a la spec, y la suite lo sigue.
8:15 · Conclusión
La spec primero, en lenguaje humano. La prueba a partir de la spec. La biblioteca a partir de la prueba. Cada eslabón vigilado por un script. Observado, derivado, vigilado, y mantenido vivo cuando el sistema cambia. Gracias por caminar con Stedd, MCP y Terra.
Definición en el glosario, la diferencia con TDD en las preguntas frecuentes y el método completo en rf-test-agents. El siguiente vídeo muestra el mecanismo que permite a estos agentes pilotar SAP.
Cómo pilotan SAP los agentes de IA: MCP, rf-mcp, los plugins de SAPFX y qa-brain
Cómo SAPFX conecta agentes de IA a sistemas SAP reales, capa a capa: el protocolo MCP, el servidor genérico rf-mcp y sus tres plugins SAP (uno por canal: SAP GUI, Fiori, API), la fina capa sapfx-mcp y su guarda de compatibilidad, qa-brain, la memoria QA del equipo servida por un segundo servidor MCP, las llaves de cada agente, las lecciones aprendidas en vivo y, por último, el punto clave: MCP sirve para el diseño, y la suite que deja se reproduce sin agente y sin tokens.
Cómo pilotan SAP los agentes de IA · 8 min 20 · en inglés, voz sintética, subtítulos en español. Stedd (el agente de IA), MCP (el mensajero), Terra (el sistema SAP real) y qa-brain (la memoria del equipo) siguen un viaje de ida y vuelta real en SE16, del protocolo a la pantalla SAP. El hilo conductor: el agente habla MCP, los plugins hablan SAP, la memoria recuerda y el sistema real decide.
Leer la transcripción en español
0:00 · Apertura
Un agente de IA no puede hacer clic por sí solo en una pantalla SAP. Necesita un protocolo, un motor de pruebas y algo que hable SAP. Así es como SAPFX conecta agentes de IA a sistemas SAP reales: MCP, rf-mcp, tres plugins y una memoria compartida.
0:20 · Los personajes
Stedd es el agente de IA: un modelo de lenguaje, con un sombrero por oficio: planificar, generar, verificar, reparar. MCP es el mensajero: el Model Context Protocol, la forma estándar de que un agente llame a herramientas. Terra es el sistema SAP real. Nuestro banco de pruebas tiene dos: Terra 2023 y Terra A4H. qa-brain es la memoria del equipo: specs, keywords y lecciones de incidentes pasados, que los agentes pueden consultar.
0:49 · Lo que falta
SAP tiene tres puertas: el cliente de escritorio SAP GUI, las aplicaciones web Fiori y los servicios OData y RFC, sin pantalla alguna. Ya existe un servidor MCP genérico para Robot Framework: rf-mcp. Descubre keywords, las ejecuta en vivo y escribe suites de pruebas. Pero su guía de localizadores conoce Browser, Selenium y Appium. Los controles UI5, el WebGUI, la pantalla SAP GUI: nada.
1:19 · Componer por encima
Así que no escribimos un nuevo servidor MCP. Componemos por encima de rf-mcp, con tres plugins: uno por canal SAP. rf-mcp conserva el trabajo genérico. Los plugins añaden lo que solo SAP necesita, y las bibliotecas SAPFX pilotan de verdad. La misma regla que en el resto del proyecto: no fusionar los paradigmas en la capa técnica. Unificar por encima.
1:47 · Tres puntos de enganche
Cada plugin se engancha a rf-mcp mediante tres puntos de enganche, registrados como puntos de entrada de Python: ni fork, ni parche. Primer enganche, el mapa de keywords: Run Transaction va a la biblioteca que pilota SAP GUI, Click Ui5 Control a la de Fiori. Segundo enganche, las indicaciones: apuntar a los controles UI5, nunca a los id del DOM; juzgar un mensaje por su tipo, nunca por su texto traducido; nunca Sleep. Tercer enganche, el proveedor de estado: la pantalla SAP en vivo se convierte en el código fuente de página de la sesión. El agente ve antes de actuar.
2:25 · Un viaje de ida y vuelta
Sigamos un viaje de ida y vuelta. Stedd pide a MCP que ejecute SE16 en Terra A4H. Robot Framework la ejecuta y vuelve un ticket verde. Luego Stedd mira: el proveedor de estado devuelve la pantalla real, una línea por control, con los campos editables marcados con un asterisco. Abre la tabla T000, fija el número máximo de resultados en 300 y vuelve a mirar. Esta vez solo vuelve lo que ha cambiado: un diff de 290 bytes en lugar de 11 945. El contexto del agente se ahorra en cada turno. Y nada frágil cruza la frontera: las keywords devuelven texto plano y diccionarios, nunca un objeto COM vivo.
3:17 · Tres canales
Tres canales, tres plugins. En el SAP GUI, el plugin ECC sirve la firma de pantalla que acabamos de ver. En Fiori, rf-mcp pide la página a la biblioteca Browser, así que el plugin orienta al agente hacia una keyword: Get Ui5 Page Tree, el árbol de controles UI5. El canal API no tiene pantalla. Su plugin lo dice con honestidad y sirve en su lugar el estado real del canal: las sesiones abiertas, nunca las credenciales. Las dos rutas con pantalla se reprodujeron de principio a fin a través de rf-mcp: Fiori, 8 de 8, y SAP GUI, 9 de 9 en un sistema real.
3:58 · La capa sapfx-mcp
Hay cosas que el contrato de plugins no puede expresar. Por eso una capa fina, sapfx-mcp, monta rf-mcp sin modificarlo y añade tres herramientas. sapfx_state sirve directamente nuestra percepción: el diff por defecto, y lo que rf-mcp nunca pide, como una ventana de error aún abierta. sapfx_screenshot envía una imagen real, con recuadros numerados en cada objetivo: el agente lee un número y actúa sobre un id verificado. sapfx_reload recarga los plugins sin reiniciar el servidor. La regla: cada conexión que rf-mcp acepta en origen hace esta capa más pequeña. Nunca debe convertirse en un fork.
4:43 · La guarda
Al arrancar, una guarda de compatibilidad comprueba la versión de rf-mcp y sondea cada punto de anclaje interno que toca la capa. El 26 de septiembre salió rf-mcp 0.36. Dos días después nuestra CI se puso en rojo, aunque nadie había tocado la capa. Era la guarda, que rechazaba una versión que no había validado. Reprodujimos en ella las dos rutas y luego ampliamos la ventana. Ruidosa, nunca silenciosa.
5:12 · qa-brain, la memoria del equipo
Ahora, el segundo servidor MCP: qa-brain. Un motor de búsqueda sobre la memoria QA del equipo, que funciona en nuestras propias máquinas. Indexa keywords de Robot Framework, specs, documentación y lecciones escritas tras incidentes reales: 1383 pasajes, a 29 de septiembre. Antes de una decisión de criterio, el agente pregunta. Aquí el planner pregunta cómo encontrar un campo en una pantalla de selección de SE16, donde los campos se numeran por posición. qa-brain responde con fuentes: la keyword de la biblioteca que deduce esos campos y la spec que advirtió de ellos por primera vez. Tres reglas. El sistema en vivo decide: un pasaje es una pista, nunca una prueba. La fuente se cita. Y qa-brain nunca bloquea el trabajo. La clave: una lección que alguien ya pagó, en un incidente real, no se paga dos veces.
6:09 · Quién tiene cada llave
Cada agente recibe solo las llaves que necesita. El planner, el generator y el healer pilotan SAP a través de rf-mcp. El verifier no tiene ninguna herramienta SAP: solo lee. Eso es lo que hace que su revisión sea independiente. Los cinco pueden consultar a qa-brain, incluido el diseñador ISTQB, que trabaja sin conexión. Por encima, un hook de permisos deja pasar las lecturas y pregunta antes del resto. Solo un humano activa la autonomía.
6:47 · Aprendido en vivo
Algunas lecciones se pagaron en vivo. rf-mcp ejecuta las keywords fuera del hilo principal, y el scripting de SAP GUI es COM: cada hilo debe inicializarlo primero. El 7 de septiembre, una mirada desde el hilo equivocado volvió vacía, y en verde. Ahora falla, nombra la causa y se vuelve a conectar. El servidor también conserva el código de la biblioteca que cargó al arrancar. Cuando nuestro código cambia en disco, las respuestas de estado llevan un aviso de código obsoleto. Y una regla de higiene: una sola sesión SAP GUI viva por servidor, cerrada al final, incluso tras un fallo.
7:27 · Diseño y ejecución
Este es el punto clave. MCP sirve para el diseño: explorar, verificar cada paso en vivo, reparar, recordar. Lo que deja tras de sí es una suite de Robot Framework corriente. Se reproduce con el comando robot: sin agente, sin MCP, cero tokens.
7:49 · Resumen
Agente, protocolo, motor, plugins, bibliotecas, sistema y una memoria compartida: cada capa hace un solo trabajo.
8:01 · Conclusión
El agente habla MCP. Los plugins hablan SAP. La memoria recuerda. Y el sistema real decide. Código abierto, construido sobre rf-mcp. Gracias por volar con Stedd, MCP, Terra y qa-brain.
Los plugins y la capa sapfx-mcp forman parte de SAPFX; los agentes son los de rf-test-agents, y qa-brain es el RAG local de CabrIA. Las cifras que cita el vídeo son las de su realización, el 29 de septiembre de 2026; el 9 de octubre de 2026, qa-brain indexa 4119 pasajes. El siguiente vídeo lo resume todo en siete principios.
La mentalidad de SAPFX: siete principios, una caja de herramientas, lo que cambia
Por qué SAPFX está concebido como está, en siete principios respaldados por casos reales: unificar por encima de los canales SAP, dejar que decida el sistema real, no estar nunca en verde y falso, ver antes de actuar, la IA diseña y Robot reproduce, una carencia se convierte en capacidad, reglas aplicadas y no solo enunciadas. Después, la caja de herramientas completa y lo que cambia en la práctica, incluido lo que SAPFX no tiene (soporte del proveedor, editor gráfico).
La mentalidad de SAPFX · 11 min 11 · en inglés, voz sintética, subtítulos en español. Los personajes de los vídeos anteriores (Stedd, MCP, Terra, qa-brain) dan la bienvenida a tres recién llegados: You (la persona que decide), RF (Robot Framework en la ejecución) y Gate (las guardas mecánicas). Cada principio termina con una tarjeta «Remember» (para recordar).
Leer la transcripción en español
0:00 · Apertura
Probar bien SAP no depende de una sola herramienta. Es una forma de trabajar, y este vídeo trata de la mentalidad que hay detrás de SAPFX. Lo que construimos, cómo lo construimos y lo que cambia, contado por los personajes de nuestros vídeos anteriores y tres recién llegados.
0:18 · Los personajes
Cuatro habituales de nuestros vídeos anteriores: Stedd, el agente de IA; MCP, su mensajero; Terra, el sistema SAP real; y qa-brain, la memoria del equipo. Stedd lleva un sombrero por oficio: planificar, generar, verificar, reparar. Y Terra tiene un gemelo en nuestro banco de pruebas: Terra 2023 y Terra A4H. Tres recién llegados. You: la persona que decide. You escribe la spec en lenguaje llano y revisa lo que vuelve. RF es Robot Framework en la ejecución. Reproduce lo escrito, exactamente, tantas veces como quiera: sin agente, sin modelo, cero tokens. Y Gate: los scripts que dicen no. Sin opinión ni estado de ánimo: la misma respuesta cada vez, verde o roja.
1:04 · El problema de las pruebas SAP
SAP no es una sola aplicación. Tiene un cliente de escritorio, aplicaciones web Fiori, SAP GUI en un navegador y servicios OData y RFC. Las pruebas escritas contra él se rompen por nada: un identificador renombrado, un mensaje traducido, una espera fija que se quedó un segundo corta. Peor aún, algunas pasan cuando no deberían. Una prueba puede estar en verde y ser falsa: miró una cuadrícula vacía, o el sistema equivocado. El mercado tiene tres familias. Las suites comerciales: completas, con soporte, con licencia. Las herramientas de la propia SAP: incluidas, pero limitadas. Y el código abierto: libre y abierto, históricamente un canal cada vez. SAPFX pertenece a esta familia y aporta lo que faltaba: los tres canales. Se apoya en siete principios. Aquí están, uno por uno.
1:55 · Principio 1 · Unificar por encima
Principio uno: unificar por encima. Las pruebas hablan un solo vocabulario de negocio. Debajo, tres bibliotecas hablan cada una un lenguaje SAP. SapEccLibrary pilota el cliente de escritorio mediante su API de scripting. SapFioriLibrary pilota el navegador, con cinco formas de encontrar un control. SapApiLibrary habla OData y RFC. Y una lógica común, probada sin ningún sistema SAP, sostiene a las tres. Las mismas palabras en cada canal: contar las entradas de una tabla en pantalla, contar entidades de negocio por OData, contar registros de negocio por RFC. Así, un mismo hecho puede comprobarse dos veces: 205 productos en pantalla, 205 por OData. Tres canales coinciden incluso en el precio de un producto. Recuerde: escribir la prueba una vez, con palabras de negocio. El canal de debajo es un detalle, no una reescritura.
2:51 · Principio 2 · El sistema real decide
Principio dos: el sistema real decide. You escribe la spec en lenguaje llano: un objetivo, una historia de usuario, un escenario BDD, una prueba antigua. El planner la confronta con Terra, en vivo. Lo que el sistema refuta se pone en rojo: tres, dos y luego cinco suposiciones erróneas en tres escenarios recientes. Lo que sobrevive es la spec observada. You la revisa y queda sellada: de ella se deriva la prueba, y de la prueba, la biblioteca. Si cambia la spec sin regenerar la suite, Gate se niega: check spec sync compara una huella digital, cada vez. Es la lógica del desarrollo guiado por pruebas, un ladrillo antes: una spec que nadie ha confrontado está en verde por defecto, nunca por prueba. Recuerde: una spec que nadie ha confrontado está en verde por defecto, no por prueba. La spec observada guía la prueba.
3:44 · Principio 3 · Nunca en verde y falso
Principio tres: nunca en verde y falso. Una prueba que no puede demostrar lo que vio debe fallar, y fallar con estrépito. Las aserciones leen el tipo de mensaje, nunca el texto traducido. Y las pruebas esperan a que SAP esté inactivo, nunca una pausa fija. Nuestros dos sistemas comparten el mismo identificador y el mismo nombre de host. Solo la release los distingue, así que nuestras campañas prueban primero su objetivo. Las tablas se cargan de forma diferida. Una cuadrícula devolvió 1639 filas, solo 137 con datos. Una cuadrícula web envió 200 filas de 2000. Una tabla Fiori, 30 de 4133. Cada fila parecía perfecta. Por eso cada extracción se contrasta con el total que declara la tabla, y se rechaza cuando difieren. Y cuando la percepción no puede leer la pantalla, ahora falla y nombra la causa, en lugar de dar una respuesta vacía y en verde. Recuerde: una prueba que no ve debe fallar, con estrépito. Los objetivos se prueban, los totales se declaran.
4:53 · Principio 4 · Ver antes de actuar
Principio cuatro: ver antes de actuar. Un agente nunca actúa según lo que recuerda de una pantalla, solo según lo que percibe ahora. Las bibliotecas leen la pantalla en vivo como texto: cada campo, su etiqueta, su valor. O como un mapa numerado, para que el agente diga: rellena el número uno. Tras una acción, solo vuelve la diferencia: 290 bytes, en lugar de 11 945 de toda la pantalla. Los localizadores pueden ser humanos: rellenar el campo llamado Table Name. La etiqueta debe apuntar a un solo campo, o el paso falla. Cuando un identificador deriva, la biblioteca propone la coincidencia más cercana, con puntuación, y registra cada reparación. El healer parchea la capa compartida, nunca la prueba. Recuerde: el agente actúa según lo que percibe, no según lo que recuerda. Cada reparación queda registrada, nunca en silencio.
5:50 · Principio 5 · La IA diseña, Robot reproduce
Principio cinco: la IA diseña, Robot reproduce. En el diseño, los agentes trabajan mediante MCP, sobre el sistema real. El planner explora, el generator ejecuta cada paso antes de escribirlo, un verifier independiente solo lee, y el healer repara. Consultan qa-brain antes de tomar una decisión de criterio. Y solo You puede activar el modo autónomo: un interruptor reservado a las personas. Lo que los agentes dejan es una suite de Robot Framework normal y corriente. RF la reproduce tantas veces como quiera, sin agente ni modelo: cero tokens. Los tokens se pagan una sola vez, en el diseño: 3,8 millones para nuestro escenario Business Partner. Su reproducción tarda treinta segundos, y cero tokens. RF ejecuta también un centinela de deriva: pantallas vigiladas comparadas con su referencia, sin ninguna prueba escrita. Informa de un cambio y nunca lo califica de bug. Recuerde: los tokens se pagan una sola vez, en el diseño. Lo que queda es Robot Framework normal, reproducido gratis.
6:59 · Principio 6 · Una carencia se convierte en capacidad
Principio seis: una carencia se convierte en capacidad. Cuando una campaña se topa con un muro en un sistema real, la corrección no se queda en la prueba. Se convierte en una keyword de la biblioteca, con su prueba unitaria, su página de documentación y su entrada en el changelog. Luego se publica en PyPI, para todos. El siete de septiembre, una campaña enumeró dieciocho cosas que nuestra biblioteca de escritorio aún no sabía hacer, cada una reproducida por una prueba. Las correcciones se publicaron esa misma noche. Reproducido tal cual, el registro se puso en rojo dieciocho veces, nombrando cada nueva capacidad. Así sabemos que mide. Recuerde: un muro hallado en un sistema real se convierte en una keyword de la biblioteca. La corrección se entrega a todos, nunca oculta en una prueba.
7:51 · Principio 7 · Reglas aplicadas
Principio siete: las reglas se aplican, no solo se enuncian. Una regla que nadie comprueba es solo un deseo. Gate bloquea una suite más antigua que su spec, un identificador SAP en bruto en una prueba, un archivo de código de más de 500 líneas, una cifra de nuestra comunicación que el código no respalda. Bloquea una cobertura inferior al 85 %, y cualquier archivo privado camino del repositorio público. Estos controles se ejecutan en CI, y la mayoría también tras cada edición. Varias de estas reglas nacieron de un incidente real. Escritas en un script, no pueden olvidarse, y nunca discuten: verde, o rojo. Recuerde: una regla que nadie aplica es un deseo. Aquí, los scripts dicen no, de la misma manera cada vez.
8:46 · La caja de herramientas
Esta es toda la caja de herramientas. Tres bibliotecas y su núcleo común, en PyPI, bajo Apache 2.0. Dos grabadores, de escritorio y web: You recorre un flujo con el ratón y obtiene una suite de Robot, keywords de negocio, un borrador de spec, un caso de prueba ISTQB y un informe. Cinco agentes y una skill. rf-mcp con tres plugins SAP y su capa, y qa-brain, la memoria del equipo. Un centinela de deriva, líneas base visuales, telemetría de reparación, una comprobación de postura de seguridad y la extracción de tablas a cinco formatos, de CSV a Parquet. Y para el puesto de trabajo, un pack para Windows que se instala con un solo comando, con documentación en inglés y en francés.
9:39 · Lo que cambia
Entonces, ¿qué cambia? Primero, es abierto: Apache 2.0, sin coste de licencia, sin dependencia de proveedor, y el código de las bibliotecas se puede leer. Un solo vocabulario de negocio para el escritorio, la web y el canal API, allí donde las herramientas de código abierto cubrían históricamente un canal cada una. La IA donde ayuda, en el diseño, y una reproducción determinista en la ejecución. Y la spec se observa en el sistema real, no se da por supuesta. Hechos, no promesas: 321 escenarios validados en vivo en cuatro sistemas SAP reales, y 2560 pruebas unitarias con un 94 % de cobertura. Lo que no tiene: soporte del proveedor y un modo sin código. Las suites comerciales ofrecen ambos, y para algunos equipos importan. Nuestro lugar en el mapa: las capacidades de una suite comercial, al coste del código abierto.
10:39 · Conclusión
Siete principios: unificar por encima, el sistema real decide, nunca en verde y falso, ver antes de actuar, la IA diseña y Robot reproduce, una carencia se convierte en capacidad, y las reglas se aplican, no solo se enuncian. You decide lo que importa. Los agentes hacen el trabajo de campo. RF reproduce, gratis. Y suponga lo que suponga cada uno, el sistema real decide.
Es la síntesis de los tres vídeos anteriores: la IA en las pruebas, el método STDD y los agentes que pilotan SAP. Las bibliotecas son las de SAPFX, los agentes los de rf-test-agents. Las cifras que cita el vídeo son las de su realización, el 30 de septiembre de 2026; en la versión 0.8.5 del 13 de octubre de 2026, SAPFX suma 462 escenarios validados en vivo en cuatro sistemas SAP reales, 3959 pruebas unitarias y un 95 % de cobertura de código.
Hablemos de su proyecto
Automatización SAP, IA local o calidad del software: hable con nuestro equipo técnico.
- Un intercambio técnico, no comercial
- Sus datos permanecen en Francia