Glosario · El vocabulario de la QA y de la IA

Un programa que pilota un gran modelo de lenguaje para encadenar acciones sobre un sistema real, en lugar de limitarse a producir texto. En SAPFX, cinco agentes planifican, generan, reparan, verifican y documentan las pruebas pilotando un sistema SAP real mediante MCP, siempre bajo revisión humana.

La optimización de un contenido para que lo entiendan y lo citen los asistentes de IA como ChatGPT, Claude, Perplexity o Gemini, y no solo los motores de búsqueda clásicos. En la práctica: datos estructurados, respuestas autónomas y hechos verificables.

El reentrenamiento de un modelo existente sobre un corpus específico para especializarlo. CabrIA prevé aplicar este principio localmente, sobre las ejecuciones de prueba reales del cliente, para que el modelo hable el vocabulario de su negocio sin que los datos salgan de la infraestructura. El primer fine-tuning sigue pendiente: a 9 de octubre de 2026, el conjunto de entrenamiento reúne 1892 ejemplos admitidos.

Un modelo entrenado con grandes volúmenes de texto, capaz de comprender una instrucción en lenguaje natural y de responderla. En QA, sirve para generar casos de prueba, explicar un fallo o traducir una especificación en un escenario ejecutable.

Un protocolo abierto que expone herramientas y fuentes de datos a un modelo de IA de forma normalizada. SAPFX se apoya en el servidor rf-mcp para que un agente pilote Robot Framework y un sistema SAP real, en lugar de adivinar lo que ocurre en la pantalla.

El conjunto de técnicas que permiten a una máquina analizar el lenguaje humano. En QA, el NLP sirve sobre todo para relacionar una especificación redactada en español con los casos de prueba que la cubren.

Un despliegue en la infraestructura del cliente, en lugar de en una nube pública. La regla de oro en AI Cabra es 100 % on-premise o nube soberana (Francia, UE): los datos de prueba, el código fuente y los registros no salen de su perímetro.

Una técnica que combina búsqueda documental y generación: el modelo responde a partir de documentos recuperados en el momento de la pregunta, y no solo de su memoria de entrenamiento. CabrIA lo utiliza en su servidor qa-brain, en servicio (4119 pasajes indexados el 9 de octubre de 2026, búsqueda densa con BM25 como complemento): cada respuesta cita sus pasajes, y una respuesta sin cita se rechaza y se sustituye por los pasajes en bruto.

El análisis automático de imágenes. En las pruebas de software, permite localizar un elemento de la interfaz o una regresión visual cuando no hay ningún identificador técnico fiable disponible en el DOM.

Una arquitectura de red neuronal en la que solo se activan algunas subredes especializadas («expertos») para cada token generado. En CabrIA, un modelo MoE de 35 000 millones de parámetros en total solo activa unos 3000 millones de parámetros por token, lo que conserva una amplia capacidad de razonamiento con un rendimiento medido de unos 100 tok/s en una estación de trabajo local, según las condiciones.

La arquitectura cognitiva que separa el saber hacer duradero (convenciones, reglas de sintaxis, reflejos de autorreparación), destinado a los pesos del modelo mediante un fine-tuning LoRA SFT/DPO aún por realizar, de los hechos volátiles (versiones de pantallas, trampas recientes, tickets), conservados en un RAG local híbrido, el servidor FastMCP qa-brain, en servicio: 4119 pasajes indexados el 9 de octubre de 2026. Cada respuesta del RAG cita sus pasajes; una respuesta sin cita se rechaza.

La implementación asíncrona de alto rendimiento del Model Context Protocol en Python. Es el motor de interconexión que utiliza CabrIA para su servidor de memoria qa-brain.

El recurso a un modelo de IA externo e independiente (de 30 000 millones de parámetros en el caso de CabrIA) para puntuar y validar los casos de prueba generados, de modo que el modelo principal no sea el único juez de sus propias producciones: el juez confirma las notas y las deja trazadas, sin pretender eliminar todo sesgo.

Un entorno de hardware de desarrollo y de inferencia basado en dos estaciones de trabajo con memoria unificada (128 GB), sin clúster de centro de datos: servicio local de los modelos en formato cuantizado GGUF, con un rendimiento histórico de unos 100 tok/s según las condiciones, y un primer entrenamiento LoRA en bf16 previsto. Busca una IA de pruebas soberana y local sin suscripción en la nube por token; no se garantiza ningún rendimiento.

La especificación formal de AI Cabra que define las fronteras de intervención, los contratos de entrada y salida y las responsabilidades estancas de los cinco agentes de prueba de rf-test-agents (rf-planner, rf-generator, rf-healer, rf-verifier, rf-istqb). Ningún agente juzga su propio trabajo, y cuatro controles mecánicos, ejecutados en integración continua en cada push y por un hook de edición de Claude Code, verifican lo que escriben los agentes.

El servidor MCP estándar para Robot Framework que permite a los agentes de IA pilotar la ejecución de palabras clave e inspeccionar el estado del sistema de destino en sesión activa. Materializa el bucle percibir → actuar → percibir, asegurando que cada paso de una prueba se valida en vivo sobre la aplicación viva antes de escribir cualquier código.

La disciplina que diseña sistemas en los que los agentes de IA no se limitan a responder, sino que actúan: separa el razonamiento, la autorización, la ejecución y la verificación, para que un resultado se apoye en hechos observables y no en el veredicto del agente. Un método que utiliza agentes, como el STDD, no es por ello una arquitectura agéntica. Es el ámbito de CabraMesh, nuestros trabajos V2 todavía en investigación.

El enfoque que elige un modelo para un trabajo concreto en lugar de un único modelo para todo: sus capacidades se cualifican con casos representativos y después se comparan en calidad, latencia y recursos, sobre una infraestructura local. Cambiar de modelo no debe cambiar las reglas de negocio. Es una línea de investigación de CabraMesh; multiplicar los modelos no es en sí una prueba de progreso.

La representación de una interfaz tal como la exponen el navegador y las tecnologías de apoyo: roles, nombres, estados. Una prueba puede resolver en él sus destinos con getByRole, en lugar de depender de selectores CSS o XPath que el menor cambio de maquetación rompe; es el enfoque previsto para CabraFlow, en diseño.

La capacidad de una prueba para volver a encontrar por sí sola un elemento cuyo localizador ha cambiado. En SAPFX, la reparación siempre queda registrada, nunca es silenciosa: una corrección invisible convertiría una prueba en un falso testigo.

La descripción de una situación que hay que verificar: un estado inicial, unas acciones, un resultado esperado. Es la unidad básica de la QA, y lo que nuestras herramientas y agentes ayudan a producir y luego a mantener automáticamente.

Una vista de la pantalla pensada para un agente de IA: cada objetivo accionable recibe un número, con su etiqueta legible, su identificador y su valor (Get Screen Map), y la captura anotada dibuja esos números sobre la imagen (Get Annotated Screenshot). El agente indica un número y la biblioteca actúa sobre un identificador verificado; reservado al pilotaje interactivo, nunca en una suite entregada.

La integración y la entrega continuas: la cadena que compila, prueba y despliega automáticamente con cada modificación del código. Las pruebas automatizadas solo tienen valor si están conectadas a ella, porque es ahí donde se ejecutan sin intervención manual.

La parte del código o de los recorridos de negocio que las pruebas ejercitan realmente. SAPFX mide un 95 % de cobertura de código en integración continua sobre sus 3959 pruebas unitarias reproducidas sin SAP (versión 0.8.5), con un umbral mínimo estricto del 85 % impuesto en CI; sus 462 escenarios validados en vivo en sistemas SAP reales cubren, por su parte, recorridos de negocio.

La medición objetiva e instrumentada de las líneas de código ejecutadas durante las pruebas automatizadas. En SAPFX, la cobertura se mide con pytest-cov en integración continua: un 95 % en la versión 0.8.5, con un umbral mínimo estricto del 85 % impuesto en CI. Indica qué parte del código ejecutan las pruebas, no que ese código esté libre de defectos de negocio.

Un colector pasivo que intercepta todas las interacciones de prueba (listeners de Robot Framework, reporters de Playwright, hooks MCP). Integra un depurador (scrubber) automático que enmascara sobre la marcha las contraseñas, las claves de API y los datos personales antes de cualquier archivado en el corpus de aprendizaje. El 9 de octubre de 2026, la recopilación de CabrIA suma 4 146 190 registros consolidados; un registro no es un ejemplo admitido ni un escenario validado.

Una regla estricta de higiene que prohíbe integrar en un conjunto de datos cualquier escenario o código de prueba sintetizado por una IA sin que haya superado un dryrun y una ejecución real completa contra fixtures sin conexión. Esta validación sistemática del código generado sigue pendiente antes del entrenamiento. No debe confundirse con las pruebas del propio software CabrIA: 1070 superadas de 1071 el 9 de octubre de 2026 (la última consulta los servicios reales del laboratorio y superó su tiempo límite), que no miden la calidad del modelo.

El International Software Testing Qualifications Board, el organismo cuyo marco de referencia y vocabulario sirven de estándar para la documentación de pruebas. Los agentes sap-istqb y rf-istqb estructuran planes y casos de prueba según este marco; CabraFlow, en diseño, prevé una exportación documental en este formato.

Un enfoque en el que la prueba se escribe con palabras clave de negocio reutilizables, mientras la mecánica técnica permanece en una capa separada. Un probador funcional lee y modifica la prueba sin leer código, y un cambio técnico se corrige en un único punto centralizado.

La expresión que designa un elemento de la interfaz para que una prueba pueda actuar sobre él. En SAPFX, los localizadores viven en una capa de recursos separada, nunca en medio de las pruebas: eso es lo que permite corregirlos sin tocar los escenarios.

Una biblioteca de código abierto de Microsoft para pilotar navegadores modernos, con esperas automáticas y selección por rol de accesibilidad. SapFioriLibrary se apoya en ella a través de la biblioteca Browser; CabraFlow, en diseño, prevé apoyarse también en ella.

Un marco de automatización de código abierto, keyword-driven, en el que la prueba se lee como una serie de frases de negocio. Es la base de SAPFX, de ODOOFX y de rf-test-agents, y uno de los tres destinos de exportación previstos para CabraFlow, en diseño.

Una prueba que recorre un proceso de negocio completo a través de todos sus sistemas, como lo haría un usuario real. En SAP, un solo recorrido puede atravesar SAP GUI, Fiori y una API OData, lo que explica que SAPFX cubra los tres canales sin interrupción.

Una prueba que recorre varios canales de un mismo sistema: prepara por la API, actúa en la pantalla y verifica por un canal independiente, en el mismo informe de Robot Framework. Ejemplo validado en vivo: un mismo precio de producto leído por OData, por el WebGUI y por RFC, y los tres valores comparados entre sí. Ver nueve pruebas híbridas.

La medición del comportamiento de una aplicación bajo carga: tiempos de respuesta, resistencia al aumento de carga, cuellos de botella. AI Cabra ofrece auditorías y pruebas de rendimiento cuyo análisis está asistido por la IA.

Un script determinista, ejecutado en integración continua en cada push y por un hook de edición de Claude Code, que sustituye las instrucciones en lenguaje natural dadas a la IA por verificaciones mecánicas (procedencia SHA256 del plan de prueba, rechazo de los selectores CSS/XPath en bruto, prohibición de Sleep). rf-test-agents cuenta con cuatro: una desviación hace fallar la integración continua, y check_conventions bloquea también la propia edición.

El control que rechaza una lectura de tabla amputada: una cuadrícula o una tabla a menudo solo devuelve una parte de sus filas, todas limpias, sin nada que señale lo que falta. SAPFX contrasta el número de filas leídas con el total que declara la tabla (Table Extract Should Be Complete), en SAP GUI, el WebGUI, SAPUI5 y RFC.

El registro transparente (consignado en docs/heal-journal.md) que documenta cada recalibración automática de localizador realizada por rf-healer: marca de tiempo, localizador obsoleto, nuevo localizador validado y justificación técnica. Garantiza que ninguna reparación sea silenciosa y ofrece a los auditores una trazabilidad completa de la evolución del código.

Comprobar, antes de cualquier lectura o escritura, que la prueba se dirige al sistema previsto, con un criterio que distinga realmente dos sistemas: la release, el kernel, el mandante servido. Dos sistemas pueden anunciar el mismo identificador y el mismo nombre de host; System Identity Should Be rechaza entonces el objetivo en lugar de leer el sistema equivocado.

Saber qué pruebas volver a ejecutar cuando llega un transporte a un sistema SAP. SAPFX lee el transporte por RFC, en solo lectura, sigue cada objeto a través de un nivel de uso, cruza los nombres con las suites de Robot Framework según lo que cada prueba ejecuta de verdad y, después, una persona decide, suite por suite, volver a ejecutar o descartar con su motivo; la decisión queda registrada y ligada a la huella del impacto. Publicado en la versión 0.8.5 de las bibliotecas (13 de octubre de 2026). Ver la sección.

Una regla que decide, antes de cualquier gesto de escritura, si SAPFX puede escribir en el sistema SAP: solo lectura, exploración (una aprobación por gesto) o completo, con una pista de auditoría de las decisiones. En modo humano, la aprobación viene de una persona, mediante la herramienta MCP sapfx_approve_write del taller o un cuadro de entrada donde escribe una palabra de confirmación, y solo cubre un destino; un agente no puede aprobarse a sí mismo. Una salvaguarda operativa, no un control de seguridad: la barrera sigue siendo la autorización SAP del usuario de prueba. Publicada en la versión 0.8.5 de las bibliotecas; la herramienta MCP pertenece al taller, no al paquete de PyPI. Ver la sección.

Una decisión de entrega calculada sobre el archivo de resultados de una ejecución de Robot Framework: pruebas ejecutadas, fallos, saltos sin motivo, capturas de error en una prueba verde, localizadores reparados, planes modificados desde la generación. Tres perfiles (estricto, estándar, aumento progresivo), criterios explícitos, y un criterio ilegible se cuenta como no medido, nunca como cero. Publicado en la versión 0.8.5 del paquete. Ver la sección.

La mentalidad común de SAPFX, ODOOFX y rf-test-agents. La especificación es una visión de conjunto en lenguaje humano, estructurada o no (objetivo de negocio, historia de usuario, escenario BDD, caso de prueba existente); el planner la confronta con el sistema real y redacta su versión observada en specs/, revisada por una persona, que se convierte en la fuente de verdad; la suite de pruebas se deriva de ella (cada paso ejecutado en vivo antes de escribirse, huella SHA256 del plan verificada por un control); y lo que una prueba exige sin que la biblioteca sepa hacerlo se convierte en una keyword de la biblioteca, nunca en un rodeo dentro de una suite. El BDD es una forma de especificación, no un competidor; lo que distingue al STDD es que la versión observada es la de referencia y guía también el código de automatización. La misma lógica que TDD, un ladrillo antes: la spec, verde por defecto en teoría, se confronta con el sistema real antes de escribir ningún test. STDD es un método que utiliza agentes, no una arquitectura agéntica. rf-test-agents V1.0.0 es la herramienta libre bajo Apache 2.0 que lo aplica. CabraMesh es el nombre de nuestros trabajos V2 en ingeniería agéntica: roles acotados, modelos locales adaptados a las tareas, acciones controladas y evidencias verificables. CabraMesh sigue en investigación; no se afirma ningún despliegue ni mejora medida. Descubrir CabraMesh: ingeniería agéntica V2.

Véase también: el vídeo STDD (8 min 34), que lo muestra con un caso SAP real.

El lenguaje de programación propio de SAP, en el que está escrita la mayor parte del código de negocio estándar y específico. Los escenarios en vivo de SAPFX se ejecutan contra sistemas ABAP reales (ABAP Platform 1909 y 2023), y no contra una simulación.

Las dos generaciones del ERP de SAP: ECC, la histórica, y S/4HANA, la actual. SapEccLibrary pilota ambas mediante SAP GUI Scripting, lo que asegura los largos años de migración en los que las empresas explotan las dos en paralelo.

Una división lógica de un sistema SAP: un mismo sistema aloja varios mandantes (000 para la administración, un mandante de trabajo como 001), cada uno con sus datos de negocio, sus usuarios y su configuración. Una prueba que no comprueba su mandante puede leer las tablas correctas en el lugar equivocado: SAPFX vuelve a leer el mandante realmente servido, canal por canal, antes de cualquier escritura.

El código corto que abre una pantalla de SAP GUI: SE16 para mostrar una tabla, SM36 para planificar un job, BP para los interlocutores comerciales. Run Transaction de SapEccLibrary la abre y juzga el resultado por el tipo del mensaje de estado, nunca por su texto traducido, lo que funciona sea cual sea el idioma de conexión.

La interfaz de automatización integrada en el cliente pesado SAP GUI, que permite pilotar las pantallas mediante programación. Es el mecanismo en el que se basa SapEccLibrary. Su equipo Basis debe activarla tanto en el servidor como en el cliente.

El dynpro es la pantalla clásica de una transacción SAP GUI, en la que cada campo y cada botón lleva un identificador técnico; el table control es la tabla de entrada que contiene, como la lista de campos de una tabla en SE11. SapEccLibrary lee un table control por título de columna (Read Table Control), ventana por ventana, y solo devuelve las filas realmente rellenadas.

La transacción estándar que muestra el contenido de una tabla SAP. SAPFX la utiliza para contar y leer tablas por la pantalla, por ejemplo para contrastar el número de registros visto en SAP GUI con el que devuelve un servicio OData o el canal RFC en el mismo sistema. Una estructura, que no es una tabla, se rechaza allí con un mensaje de tipo E.

La cuadrícula de lista estándar de SAP (ALV, ABAP List Viewer), presente en la mayoría de los informes. Solo carga sus filas al desplazarse y muestra las demás como celdas vacías: una lectura puede tener el número correcto de filas y estar hueca. Read Full Grid desplaza la cuadrícula para leerlo todo y Count Blank Grid Rows rechaza una lectura hueca; las columnas se leen por identificador técnico, independiente del idioma.

El mensaje que aparece al pie de una pantalla SAP tras una acción, con un tipo (S éxito, E error, W advertencia, A cancelación, I información), una clase y un número. SAPFX juzga un resultado por el tipo y el identificador del mensaje (por ejemplo MO/E/402), nunca por su texto, traducido al idioma del usuario.

La versión de navegador de SAP GUI, servida por el servidor ABAP: las mismas transacciones, mostradas en HTML. SapFioriLibrary la pilota por el SID de cada elemento, el mismo identificador que el scripting de escritorio, y lee sus cuadrículas contrastando las filas recibidas con el total que declara la cuadrícula: el WebGUI solo envía una página de filas, renumeradas a partir de 1.

El lenguaje de diseño de las interfaces web modernas de SAP, que sucede a las pantallas del cliente pesado. Técnicamente, una aplicación Fiori es una aplicación SAPUI5.

La biblioteca JavaScript de SAP en la que se ejecutan las aplicaciones Fiori. Sus identificadores de elementos cambian dinámicamente de una ejecución a otra: la compatibilidad de SapFioriLibrary está demostrada de UI5 1.71 a 2.0 para absorber esta variabilidad.

El punto de entrada de las aplicaciones SAP Fiori: mosaicos agrupados por catálogo, algunos de los cuales muestran un contador. SapFioriLibrary abre una aplicación por su intent semántico (Open Fiori App), la vía estable que resiste al tema y al idioma, y espera a que el contador de un mosaico esté realmente cargado antes de leerlo (Wait For Flp Tile Counter).

Plantillas de aplicaciones SAP Fiori generadas a partir de las anotaciones de un servicio OData: lista (List Report) y ficha (Object Page). Sus identificadores de controles son estables, lo que los convierte en buenos anclajes de prueba; una tabla solo muestra allí sus filas instanciadas, de ahí el contraste con el total declarado antes de cualquier extracción.

Un protocolo de API REST normalizado que SAP utiliza para exponer sus datos a las aplicaciones Fiori y a sistemas de terceros. SapApiLibrary cubre de forma nativa OData v2 y v4.

El componente del servidor ABAP que publica los servicios OData. SapApiLibrary lee su catálogo de servicios y el contrato $metadata con sus etiquetas, gestiona el token CSRF de las escrituras y agrupa varias peticiones en un único $batch. Su control previo nombra la causa de un servicio inactivo en lugar de dejar que una prueba falle con un error mudo.

Una vista de datos definida en ABAP Core Data Services, sobre la que se apoyan las aplicaciones SAP Fiori y los servicios OData modernos de SAP S/4HANA. Una prueba SAPFX puede contar las filas de una vista CDS por RFC y contrastar ese número con el contador que muestra un mosaico del launchpad, sin redondeo ni tolerancia.

El modelo de programación actual de SAP para las aplicaciones transaccionales, borradores incluidos. El servidor ABAP genera sobre la marcha una vista previa SAP Fiori Elements de cualquier servicio RAP publicado: Build Fe Preview Path construye su dirección, lo que permite probar la interfaz sin ninguna aplicación desplegada.

El protocolo nativo de SAP para la llamada remota a funciones y BAPI. En SapApiLibrary, el canal RFC, opcional, pasa por pyrfc: lectura de tablas (Read Rfc Table), BAPI juzgadas por tipo de mensaje (Call Bapi, Commit/Rollback Bapi Transaction), jobs de fondo y spool (Wait For Background Job, Read Job Spool), IDoc (Create Outbound Idoc, Wait For Idoc Status), configuración y superficie de seguridad ABAP en solo lectura.

Una interfaz de programación de negocio estándar de SAP, llamada por RFC para leer o modificar un objeto (un interlocutor, un pedido). Call Bapi de SapApiLibrary juzga su resultado por el tipo de los mensajes de la tabla RETURN (E, A o X hacen fallar la llamada), nunca por su texto, y Commit Bapi Transaction confirma la transacción.

El documento intermedio de SAP para intercambiar datos entre sistemas (ALE, EDI), seguido mediante una serie de estados numéricos. SapApiLibrary crea un IDoc de salida, espera su estado por su código (Wait For Idoc Status; 03: transferido al puerto) y encuentra el IDoc de entrada vinculado por el identificador de transacción tRFC, nunca por la marca de tiempo.

Un job es un programa planificado en SAP (transacción SM36, seguimiento en SM37); el spool conserva la lista que imprime (SP01). SapApiLibrary espera un job mediante un sondeo acotado de la tabla de jobs (Wait For Background Job), sin pausa fija, y lee su spool por dos vías independientes. Un paso que no imprime nada no tiene spool, algo que SAPFX distingue de un spool vacío.

SAP BTP es la plataforma en la nube de SAP; SAP Build Work Zone publica en ella sitios y launchpads, protegidos por un proveedor de identidad. SapFioriLibrary se conecta mediante el formulario del proveedor de identidad (Log In Via Identity Provider) y entra en la aplicación abierta en su iframe; SapApiLibrary abre el canal API del sitio en OAuth2 con una clave de servicio.

La herramienta de prueba histórica integrada en SAP Solution Manager 7.2, cuyo mantenimiento estándar termina el 31 de diciembre de 2027 (nota SAP 3585220). SAP orienta hacia SAP Cloud ALM, que gestiona y sigue las pruebas; su ejecución automatizada pasa por herramientas que se conectan a él, y los escenarios CBTA existentes deben retomarse en otra herramienta. SAPFX es una vía abierta, sin licencia, para reescribirlos en Robot Framework.

La herramienta de pruebas automatizadas integrada en el servidor ABAP (extended Computer Aided Test Tool), que graba y reproduce transacciones. Sigue disponible; sus escenarios pueden reescribirse en Robot Framework con SAPFX cuando un equipo quiere una sola herramienta para SAP GUI, SAP Fiori y las API.

SAP Solution Manager 7.2, que incluye CBTA, llega al fin de su mantenimiento estándar el 31 de diciembre de 2027 (nota SAP 3585220). SAP orienta hacia SAP Cloud ALM, que gestiona y sigue las pruebas; su ejecución automatizada pasa por herramientas que se conectan a él.

La transacción estándar de SAP que analiza la carga de trabajo del sistema: frecuencia, volumen y tiempos de respuesta de las transacciones y los programas ejecutados realmente. Ayuda a elegir qué transacciones probar primero, las que la empresa utiliza de verdad.

Nuestro ecosistema de código abierto de automatización de pruebas SAP para Robot Framework, con licencia Apache 2.0, distribuido en PyPI con el nombre robotframework-sapfx (versión 0.8.5 del 13 de octubre de 2026). Tres bibliotecas cubren SAP GUI para Windows, SAP Fiori, SAPUI5 y SAP GUI for HTML, OData y RFC/BAPI, y una misma prueba puede recorrer varios canales, sin licencias que pagar ni dependencia del proveedor. Concebido para probar, también sabe escribir, eliminar y contrastar sus escrituras por un segundo canal, lo que abre, como rumbo, la generación de conjuntos de datos, la población de bases de datos para las pruebas de rendimiento y la carga de datos de parametrización o de migración. Descubrir SAPFX.

Véase también: la página «SAPFX en imágenes», con capturas tomadas en directo y extractos de suites validadas, y el vídeo «The SAPFX mindset» (11 min 11), que resume su mentalidad en siete principios.

Las tres bibliotecas de SAPFX, 442 palabras clave documentadas en la versión 0.8.5: SapEccLibrary (195) para SAP GUI para Windows (ECC y S/4HANA), SapFioriLibrary (98) para SAP Fiori, SAPUI5 y SAP GUI for HTML sobre Playwright, y SapApiLibrary (149) para las API OData v2/v4 y RFC/BAPI; el canal RFC, opcional, pasa por pyrfc. Referencia de las palabras clave (en inglés).

Los plugins de SAPFX del servidor MCP rf-mcp (SAP GUI, SAP Fiori, API) dan a un agente de IA la percepción de la pantalla SAP y la ejecución de las keywords paso a paso; la capa sapfx-mcp añade el estado de la sesión, la captura de pantalla, la recarga en caliente y, desde el 9 de octubre de 2026, la aprobación por una persona de una escritura en SAP (sapfx_approve_write), sin modificar rf-mcp. Forman parte del taller SAPFX, no del paquete PyPI, que contiene las bibliotecas. El puente MCP entre las herramientas del taller.

Dos grabadores transcriben un recorrido real en keywords de Robot Framework: una extensión de navegador para SAP Fiori y el WebGUI, y un grabador de escritorio para SAP GUI. Exportan una suite completa, un par resource y suite sin identificador bruto en la prueba, un plan de pruebas y un informe HTML; el recorrido grabado sigue siendo un borrador que hay que revisar. Verlos en acción; sus opciones y sus límites.

Cinco agentes especializados: sap-planner contrasta la petición con el sistema real y escribe un plan observado, sap-generator ejecuta cada paso antes de escribirlo, sap-healer repara la capa de resources sin tocar las aserciones, sap-verifier revisa en modo de solo lectura y sap-istqb documenta y revisa el diseño de las pruebas según ISTQB. Aplican el método STDD, bajo control humano, en el taller SAPFX. Los agentes y su marco.

La herramienta del taller SAPFX que puntúa una petición de prueba, un prompt confiado a los agentes de IA, antes de que los agentes la traten: su forma y su parte de plantilla se verifican sin llamada a un modelo, un modelo de lenguaje, local por defecto, que puntúa cero cuando no responde, juzga ocho criterios (intención, hechos frente a hipótesis, nivel de prueba, aserción, objetivo, repetibilidad, capacidades, postura), y una sonda RFC en solo lectura verifica que las transacciones, tablas y módulos de función nombrados existen en el sistema objetivo. La puntuación mide la redacción, no el coste; «jugable» no exime de la exploración en el sistema. Añadido el 10 de octubre de 2026. Prompt Eval entre las herramientas del taller.

Nuestra suite de código abierto de agentes de ingeniería de QA para Robot Framework, con licencia Apache 2.0, distribuida en GitHub (CyrilM29/rf-test-agents, versión 1.0.0). Implementa la arquitectura Agent Contract v1 (5 agentes especializados), el protocolo estándar rf-mcp (RobotMCP) y 4 controles mecánicos deterministas, ejecutados en integración continua en cada push y por un hook de edición de Claude Code; 310 pruebas unitarias superadas en integración continua el 5 de octubre de 2026. Descubrir rf-test-agents. STDD es un método que utiliza agentes, no una arquitectura agéntica. rf-test-agents V1.0.0 es la herramienta libre bajo Apache 2.0 que lo aplica. CabraMesh es el nombre de nuestros trabajos V2 en ingeniería agéntica: roles acotados, modelos locales adaptados a las tareas, acciones controladas y evidencias verificables. CabraMesh sigue en investigación; no se afirma ningún despliegue ni mejora medida. Descubrir CabraMesh: ingeniería agéntica V2.

El nombre de nuestros trabajos V2 en ingeniería agéntica: una arquitectura objetivo local en la que agentes con roles acotados actúan dentro de un perímetro aprobado, con modelos cualificados por tarea, controles deterministas antes de cualquier acción y evidencias verificables, bajo control humano. En investigación: no se afirma ningún despliegue ni mejora medida, y no existe repositorio público. No debe confundirse con rf-test-agents, la V1 libre (versión 1.0.0, Apache 2.0). Descubrir CabraMesh.

Nuestra vertical de código abierto de automatización de pruebas de Odoo para Robot Framework, con licencia Apache 2.0, publicada en PyPI (paquete robotframework-odoofx, versión 0.2.0 del 13 de octubre de 2026, fase alfa). Se dirige a Odoo Community y Enterprise mediante tres canales: la API RPC (XML-RPC y JSON-2) y la interfaz web (inicio de sesión, navegación, lectura de las vistas, entrada de formularios), operativas y probadas en Odoo 16 y 19, y la introspección ORM, con cinco agentes que aplican el Spec-Test-Driven Development. Descubrir ODOOFX.

Nuestro programa de I+D, sin versión publicada: un modelo de IA abierto que se especializará en Quality Engineering mediante un fine-tuning local, previsto sobre las ejecuciones de prueba reales, acoplado a una base de conocimiento RAG en la que cada respuesta cita sus pasajes. El 9 de octubre de 2026, el RAG qa-brain está en servicio (4119 pasajes indexados), se superaron 1070 de 1071 pruebas automatizadas y el conjunto de entrenamiento reúne 1892 ejemplos admitidos (a 9 de octubre); el primer fine-tuning sigue pendiente. 100 % on-premise o nube soberana (Francia, UE): los datos de prueba no salen de ese perímetro. Descubrir CabrIA.

El servidor MCP de memoria QA de CabrIA, en servicio: un RAG local que combina búsqueda densa, BM25 como complemento y reranking sobre la documentación de keywords, los planes de prueba, las guías y las lecciones extraídas de incidentes reales, con 4119 pasajes indexados el 9 de octubre de 2026. Los agentes de prueba lo consultan antes de sus decisiones; cada respuesta cita sus pasajes, y una respuesta sin cita se rechaza y se sustituye por los pasajes en bruto. Descubrir CabrIA.

Nuestro programa de I+D, en diseño, de orquestador de pruebas keyword-driven sobre Playwright. El objetivo: que el usuario muestre su negocio narrándolo en voz alta, que la prueba se escriba en microfrases de negocio y se reproduzca en tres destinos (runner nativo, exportación a Playwright y exportación a Robot Framework), en local. El 6 de octubre de 2026 hay seis especificaciones redactadas (12 de agosto de 2026), sin código, prototipo ni demostración; el modo de voz espera un criterio cuantificado (más del 85 % de pasos correctos, menos de 2 s de latencia) que nunca se ha medido. Descubrir CabraFlow.