Frequently Asked Questions · Everything you need to know

SAPFX (PyPI package robotframework-sapfx, version 0.8.5 released on October 13, 2026) is an open-source ecosystem for Robot Framework that drives SAP through three libraries: SapEccLibrary for SAP GUI for Windows, SapFioriLibrary for SAP Fiori, SAPUI5 and SAP GUI for HTML applications (on top of Playwright), and SapApiLibrary for OData and RFC/BAPI. Its first use is automating SAP tests: tests are written in business language, without technical identifiers, and a single test can cross several channels. Because it can also write, delete and cross-check what it writes through a second channel, it opens up to other uses (test data sets, databases to populate for performance testing, configuration and data migration), presented as a direction and not as delivered features. Apache 2.0 license. The “SAPFX in pictures” page shows screenshots taken live and excerpts from validated suites; the film “The SAPFX mindset” (11 min 11, with captions) sums up its mindset in seven principles.

Published on PyPI on 13 October 2026, it brings capabilities proven from 7 to 13 October 2026 on S/4HANA 1909 and ABAP Platform 2023: a session policy that decides before any write gesture (read only, explore, full) with an audit trail; the approval of a write by a human, bound to one target; a GO or NO-GO verdict computed on a run's results file; the check of the SSL certificate declared in STRUST and of the one the ICM really serves; test users and roles created then deleted over RFC; supervision of the Gateway error log; the change impact analysis of a transport; the nature of an OData service proven by its markers, the Spaces and Pages mode of the launchpad and the authorization failures read in SU53. Figures of 0.8.5: 442 keywords, each with a usage example, 3,959 unit tests, 462 scenarios run live. Details on the SAPFX page.

Yes. SAPFX is published under the Apache 2.0 license: no license fees, whatever the number of users or execution machines, commercial use included. The source code is public on GitHub (CyrilM29/robotframework-sapfx) and the package installs from PyPI, with no vendor lock-in. AI Cabra offers support, migration and training services on a quote basis.

Three channels: the SAP GUI desktop client (ECC, S/4HANA, through the SAP GUI Scripting API), Fiori/SAPUI5 web (compatibility proven from UI5 1.71 to 2.0, including SAP GUI for HTML), and APIs (OData v2 and v4, optional RFC). The same business fact can be verified through two independent channels in one suite.

It was designed for testing, and that remains its core. But what makes it reliable for testing (writing a record, reading it back through a second independent channel, the screen on one side and the API on the other, deleting it and confirming it is gone) also serves other uses: generating data sets for test campaigns, populating empty or incomplete SAP databases before performance testing, loading configuration data, or securing data injection in a migration, for example from ECC to S/4HANA. To be precise about the current state: writing, deleting and cross-checking are validated live on SAP development systems; the data set generator, performance volumes and migration loads are a direction, not delivered features, and no migration has been run yet. On a customer system, each target is handled case by case, with reversibility first.

On the scope it covers (SAP GUI, SAP Fiori, WebGUI, OData and RFC, logged locator self-healing), SAPFX meets the same need as the market's commercial testing suites, which are sold under license. What those suites provide that SAPFX does not: vendor support and a graphical editor. SAPFX tests are written as keywords that read without programming. SAPFX's angle is no license fees, longevity and openness (Apache 2.0, standard Robot Framework), not a criticism of their quality.

The most widespread open-source libraries each cover a single channel: the desktop SAP GUI for one, UI5 web outside Robot Framework for the other. SAPFX covers all three channels within Robot Framework, with a single consolidated execution report. Label-based locators, popularized by the library dedicated to SAP GUI, exist in SAPFX too (acknowledged Apache 2.0 heritage), with a strict contract: ambiguity is always flagged with candidate locators, never resolved silently.

Four mechanisms: tests contain no technical identifiers (locators live in a separate resources layer, enforced mechanically); waits track the real SAP state, never fixed sleeps; assertions read the message type, not localized text; and locator self-healing logs every repair, never silently. A drift sentinel additionally monitors UI evolution without manual test scripting.

Five AI agents plan, generate, repair, verify and document tests by driving the real SAP system over MCP (the rf-mcp server and the SAPFX plugins). Every generated step is executed live before being written, and the healing agent patches the resources layer, never the tests. Nothing is silent: a human reviews, and repairs are logged. Before writing to SAP, an agent can be held to a human's approval (the workbench MCP tool sapfx_approve_write, backed by the session policy of the libraries, published in 0.8.5), and Prompt Eval scores the test request before the agents spend their tokens. These agents are part of the SAPFX workbench, not of the PyPI package; the suite they produce replays with Robot Framework alone, without any agent.

pip install robotframework-sapfx (Python 3.10 or later, Robot Framework 7.4 or later). The SAP Fiori side can be tried without any SAP system, on the public OpenUI5 Demo Kit or an SAP Fiori Elements app served locally; SAP GUI and the APIs are validated against the free ABAP Platform Trial Docker image. Check out our Quickstart Guide, and the “SAPFX in pictures” page to see real tests.

A Python 3.10 or later environment with Robot Framework 7.4 or later, then the robotframework-sapfx package from PyPI; for SAP Fiori, the robotframework-sapfx[web] extra adds the Browser library (Playwright), and the optional RFC channel needs pyrfc. For the SAP GUI channel, SAP GUI Scripting must be enabled on both server and client sides. This is typically handled by your Basis team. The Fiori and API channels have no such requirement.

Yes, with a nuance by channel. Fiori and API tests run anywhere, including headless Linux runners. SAP GUI tests require a Windows runner with SAP GUI installed: that is a requirement of the SAP GUI Scripting API, not SAPFX. In practice, teams run both families on two different runners within the same pipeline.

We maintain it, and the code is open source under Apache 2.0 on GitHub. That is precisely the answer: you can take it, fork it and keep it alive without asking anyone's permission. At version 0.8.5, released on PyPI on October 13, 2026, the project carries 3,959 unit tests replayed without SAP in continuous integration, 462 scenarios passed live on 4 real SAP systems (campaigns from July 12 to October 13, 2026) and 95% code coverage measured in continuous integration, with an 85% floor enforced. That safety net is what makes a takeover realistic.

Standard maintenance of SAP Solution Manager 7.2, which carries CBTA, ends on December 31, 2027 (SAP Note 3585220). SAP steers customers toward SAP Cloud ALM, which manages and tracks tests; their automated execution goes through tools that connect to it. Existing CBTA scenarios must therefore be taken over in another tool. SAPFX is an open path with no license fees: scenarios are rewritten in Robot Framework, on SAP GUI, SAP Fiori and the APIs, and a migration guide from CBTA ships with the libraries. The rewrite remains real work, which we can support on a quote basis, directly or through specialized partners.

Five agents, each bounded to one role, work on the real SAP system through the rf-mcp MCP server and the SAPFX plugins, under human control: sap-planner confronts the request with the real system, perceived screen by screen, and writes an observed plan in specs/; sap-generator executes each step on the system before writing it into the .robot suite, sealed by its plan's fingerprint; sap-healer repairs the resources/ layer, never the test or its assertions, each diagnosis recorded; sap-verifier performs an independent read-only review against the business invariant and the evidence; sap-istqb structures test plans and cases following ISTQB and ISO/IEC/IEEE 29119-3, with a replay block, and reviews the design of each generated suite. They are part of the SAPFX workbench, not of the PyPI package.

Ten tools, gathered in the SAPFX workbench, optional and delivered on quote (they are neither in the PyPI package nor in the public repository): a SAP GUI recorder and a web recorder for SAP Fiori and the WebGUI; Prompt Eval, which scores a test request before it goes to the agents; five AI agents and their framework (mission contract, permission hook, handover trail); the MCP bridge (three rf-mcp plugins and the sapfx-mcp overlay, including approval by a human of a write to SAP); preventive maintenance; the interface landscape map of an SAP system (read-only RFC survey, A3 plates, report and proofs captured in SAP GUI); an example business layer; a Windows deployment pack. What they produce remains ordinary Robot Framework that runs without them. Details on the workbench tools page.

With Prompt Eval, the SAPFX workbench tool added on 10 October 2026. A test request handed to the agents is a prompt, and working it end to end costs in the order of two million agent tokens on our campaigns. Prompt Eval scores it first: its form and template share are checked without any model call; eight criteria (intent, facts versus assumptions, level of evidence, assertion, target, repeatability, capabilities, posture) are judged by a language model, served locally by default and scored zero if it does not answer; a read-only RFC probe checks that the named transactions, tables and function modules exist on the target system. The score measures how the request is written, not its cost, and "playable" does not replace exploring the system. See Prompt Eval.

They check the libraries against local test doubles: fake COM objects in place of SAP GUI, doubles of the browser and of the HTTP and RFC channels, and pure logic tested on its own. They run in continuous integration with no SAP system or user license, and measure 95% code coverage (85% floor enforced in CI). That coverage does not guarantee the absence of business defects: it is complemented by 462 scenarios passed live on four real SAP systems.

rf-test-agents, version 1.0.0, is an open-source solution under Apache 2.0 for Robot Framework testing. Five specialized agents plan, generate, heal, verify and document tests using the STDD method. Software guards check conventions and test provenance; they do not measure general model quality. The repository has 310 unit tests, all passing in CI on 5 October 2026. This available V1 is separate from CabraMesh, our V2 research in agentic architecture. Explore CabraMesh: V2 agentic engineering.

Agent Contract v1 decouples the testing lifecycle into 5 strictly compartmentalized roles to eliminate conflicts of interest: rf-planner maps and specifies test scenarios (in specs/) with ISTQB traceability; rf-generator drives the live application step-by-step prior to writing any test code; rf-healer surgically repairs locators in resources/page_objects/ without ever altering the test body; rf-verifier performs read-only audits of assertion rigor; and rf-istqb exports offline ISO/IEC/IEEE 29119-3 test documentation and traceability matrices.

The absolute golden rule of rf-generator is: no keyword or .robot scenario is committed to code without having first executed successfully live against the target application. Connected via the standard rf-mcp (RobotMCP) server, the agent follows the deterministic cycle perceive → act → perceive. It inspects the live DOM or system state after each action, permanently eliminating selector hallucinations and fabricated assertions.

To preserve the core purpose of QA, rf-healer is strictly confined to the page object automation layer (resources/page_objects/). It is programmatically forbidden from modifying test suite files in tests/, skipping steps, or weakening business assertions. If an element locator changed due to technical refactoring, it recalibrates it and logs the event in docs/heal-journal.md. If the underlying business flow itself changed, it intentionally fails and delegates back to rf-planner for human review.

Text-based system instructions given to LLMs are prone to context drift and statistical oversights. rf-test-agents enforces 4 deterministic mechanical guards, run in CI on every push and by a Claude Code edit hook: check_spec_sync.py (SHA256 provenance guard tying every test to its approved specification), check_conventions.py (strict rejection of raw CSS/XPath selectors and absolute ban on Sleep), check_guidance_sync.py (checks that the CLAUDE.md conventions are carried into the agent definitions), and check_no_em_dash.py (stylistic neutrality). If a guard fails, the CI run fails; in Claude Code, only check_conventions.py blocks the edit. Keeping the agent definitions in sync between Claude Code and GitHub Copilot is checked separately, by regen_agent_definitions.py --check.

These three pillars form a cohesive, vendor-independent software ecosystem: rf-test-agents provides the universal open-source multi-agent framework and mechanical guards for any Robot Framework project (web, API, mobile); SAPFX specializes this architecture for mission-critical enterprise ERP (SAP GUI, Fiori, OData / RFC with fully operational RFC channel) with its 5 SAP agents (rf-mcp MCP server and SAPFX plugins); and CabrIA, an R&D program, aims to supply the sovereign intelligence engine (35B MoE model with local fine-tuning planned, hybrid FastMCP qa-brain RAG already in service) to power these agents 100% on-premise or in a sovereign cloud (France, EU), without a single token leaving your perimeter.

Spec-Test-Driven Development (STDD) is the mindset shared by rf-test-agents, SAPFX and ODOOFX. Three links in a chain, each driving the next. The specification first: a broad vision in human language, structured or not (business goal, user story, BDD scenario, existing test case), which the planner confronts with the live system to write its observed version under specs/, reviewed by a human: that version is the source of truth. The test next: generated from that specification, every step executed live before it is written, the suite sealed with the SHA256 of its plan, and a plan changed without regeneration fails the guard. The development last: what the test needs and the library cannot do yet becomes a library keyword, never a workaround in a suite. The healer repairs the resources/ layer, never the test, and a changed business flow goes back to the specification. What sets STDD apart: the specification is written in human language, in any form (BDD is one of them); the version that counts is observed on the real system and mechanically guarded; and it also drives the automation code.

STDD is a method that uses agents, not an agentic architecture. rf-test-agents V1.0.0 is the open-source tooling under Apache 2.0 that applies it. CabraMesh names our V2 research in agentic engineering: bounded roles, task-appropriate local models, governed actions and verifiable evidence. CabraMesh remains under research; no deployment or measured gain is claimed. Explore CabraMesh: V2 agentic engineering.

Read against TDD. STDD keeps the logic of TDD and moves it one brick earlier. TDD is red, green, refactor: the test comes first, it fails, then the code makes it pass. In STDD the first brick is the spec, and a spec is green by default, in theory: it is written, believed and never run, so nothing can make it fail. STDD puts it to the test on the real system: red where the system refutes it, green once observed, and only then come the test and the code.

The STDD film shows it on screen: the “From TDD to STDD” chapter, at 1:00 (8 min 34 in all).

No. STDD is a method that uses agents: it puts the specification to the test against the real system before the test and the code are written. rf-test-agents (version 1.0.0, Apache 2.0) is the open-source tooling that applies it to Robot Framework. Agentic engineering addresses another question: how to organize the roles, permissions, execution and verification of agents that act. That is the scope of CabraMesh, our V2 work, still under research. Explore rf-test-agents · Explore CabraMesh.

CabraMesh is the name of our V2 research in agentic engineering: a local architecture designed to let agents act within a controlled scope, under human oversight, with every conclusion backed by evidence. Its guiding lines: specialized roles with bounded contexts, models qualified per task, execution governed by deterministic controls, and evidence that goes beyond the agent's own verdict. CabraMesh remains under research: no deployment or measured gain is claimed, its internal mechanisms are not described publicly and it has no public repository. The V1 available as open source is rf-test-agents (version 1.0.0, Apache 2.0). Explore CabraMesh.

ODOOFX is AI Cabra's Odoo vertical: an open-source Robot Framework library (Apache 2.0) to test Odoo Community and Enterprise through three channels, the web UI (Browser / Playwright), the RPC API (XML-RPC up to Odoo 18, the JSON-2 API from Odoo 19) and ORM introspection. Five agents (odoo-planner, odoo-generator, odoo-healer, odoo-istqb, odoo-verifier) apply the Spec-Test-Driven Development defined in rf-test-agents, just as SAPFX does for SAP. Version 0.2.0 has been published on PyPI since 13 October 2026 (pip install robotframework-odoofx): its RPC and web channels are proven live on Odoo 16 and 19 by 117 tests, the web client covers login, navigation, reading of views, form entry and saving, and action buttons (wizards, section and note lines and line deletion are still to cover) and no result on a customer instance is claimed. The code is public on GitHub (CyrilM29/robotframework-odoofx), the keyword documentation is online and the project is presented on the ODOOFX page.

AI Cabra builds AI-powered QA automation solutions combining machine learning, computer vision, NLP, and LLMs to detect defects earlier, generate test cases automatically, and optimize CI/CD pipelines. We offer architecture consulting, legacy migration audits with direct support or partner guidance, enterprise pilot delivery, and level-3 SLA support.

Lower QA operating costs than proprietary tools (no license fees), broader test coverage, and smooth integration into your DevOps workflows. We quantify real gains during a scoped pilot project rather than making blanket marketing promises.

No. We empower your team, we do not replace it. The tests we produce are written in business language so functional analysts can read, challenge, and update them independently. AI proposes, domain experts validate.

Yes. Our expertise includes sovereign LLM integration with RAG (Retrieval-Augmented Generation), domain fine-tuning for Quality Engineering, advanced prompt engineering, and multi-agent systems via MCP.

RAG (Retrieval-Augmented Generation) combines indexed document retrieval with neural generation to provide accurate, cited answers. We use it to index your historical test suites, functional specs, and incident tickets to guide validation workflows.

Yes, 100% GDPR compliant. Our AI models are deployed on-premise within your perimeter or in a sovereign cloud (France, EU). No sensitive data leaves your servers. We adapt the deployment to your security requirements: encryption, access control and logging.

Absolutely. Our AI agents run in isolated environments on your infrastructure. Test data, source code, and execution logs remain strictly inside your network without ever being transmitted to public third-party APIs.

It is immediately flagged. All AI suggestions and self-healing actions are strictly audited and logged, never silent. An automation test that silently fixes itself is dangerous; we always favor an explicit, visible failure over an ungrounded pass.

Our team brings together seasoned AI and QA architects from top-tier technology consulting firms with deep expertise in enterprise test automation, machine learning, and mission-critical e-commerce and ERP systems.

SAPFX costs nothing (open-source Apache 2.0). For professional services (architecture audits, direct guidance or partner referrals for legacy migrations, custom CI/CD pipelines, and training), we provide transparent quotes based on a technical scoping of your estate.

CabrIA is AI Cabra's R&D program: an open AI model specialized in Quality Engineering, intended for local fine-tuning on the team's real test executions (Robot Framework, Playwright, MCP agents) and coupled to a RAG knowledge base where every answer cites its sources. The whole system is designed to run on-premise, on a local AI workstation.

A generic assistant knows software testing in general; CabrIA is designed to learn your terrain. Planned fine-tuning is intended to embed your conventions and actions (test plan design, suite authoring, failure triage, locator healing), while the knowledge base retains volatile facts: known application traps, procedures, versions. It updates without retraining the model.

The 35-billion parameter MoE architecture activates only ~3 billion parameters per processed token. This design delivers the deep reasoning and vocabulary breadth of a massive model while preserving a compact memory footprint and high processing speed (a historical throughput of about 100 tok/s under local GGUF inference, depending on conditions, not guaranteed). It is the trade-off chosen for responsive deployment on dedicated workstations.

The ADR 0002 architecture strictly decouples durable know-how from volatile facts. Enduring expertise (Robot Framework conventions, Playwright accessibility locators, root-cause diagnosis) is intended to be learned through LoRA SFT and DPO fine-tuning, which remains pending. Volatile facts (application pitfalls, build versions, project requirements) are managed by a local hybrid RAG (FastMCP qa-brain, in service, over Qdrant dense F16 with supplementary BM25 and a reranker, 4,119 indexed passages as of 9 October 2026). Every answer cites its passages; an answer without citations is rejected and replaced by the raw passages.

No. The knowledge base and inference run on a local AI station inside your infrastructure, and training (fine-tuning), still to be carried out, is planned there too. It follows the same sovereignty principle as the rest of our solutions: zero test data sent to a cloud API.

By reading its sources. Every CabrIA answer cites the passages it stems from, allowing you to trace back to the specification, test, or ticket; an answer without citations is rejected and replaced by the raw passages. That is a design constraint, not an option: an unverifiable QA assistant has no place in a quality chain.

Two strict safeguards govern the pipeline: a universal flight recorder with an automated real-time scrubber that redacts credentials, API keys, and personal data on the fly before any storage; and a refinery with a separate judge, score confirmation and traceability. Systematic offline-fixture validation of generated code remains a milestone to complete before training. As of 9 October 2026, 1,892 training examples are accepted (917 test critiques, 526 diagnostics, 313 specification-suite pairs, 136 lessons learned). On 9 October 2026, 1,070 of 1,071 automated tests passed in a single process; the remaining test queries the lab's live services and timed out. These tests verify the software, not the quality of every model answer.

AI Cabra deliberately builds the toolchain on a cost-controlled laboratory configuration: two workstations with 128 GB of unified memory, for continuous local inference in quantized GGUF format (a historical throughput of about 100 tok/s, depending on conditions) and for the first LoRA bf16 training run, still pending. The goal is to show that an enterprise Quality Engineering AI can do without multimillion-dollar datacenter clusters and per-token cloud API subscriptions.

To limit self-evaluation bias (where a model always rates its own outputs favorably), our evaluation benchmark uses an independent 30-billion parameter benchmark judge model. This neutral arbiter grades assertion strictness, generated code cleanliness, and diagnostic accuracy against rigid rubrics. It provides score confirmation and traceability, without claiming to remove all bias; a workstation outage does not count as rejecting the candidate. The benchmark holds 77 cases, including 19 RAG cases (as of 11 September 2026).

Not yet as a product: it is an R&D program built proof-first (benchmark, capture, corpus, training, rollout). The local qa-brain RAG is in service (4,119 indexed passages as of 9 October 2026); the first fine-tuning run is still pending, on a set of 1,892 examples accepted as of 9 October 2026. We publish measurements, not promises. Contact us for a demo or to discuss it for your QA team.

CabraFlow is an AI Cabra project in design: a keyword-driven test orchestrator planned on top of Playwright. The design intent: you would demonstrate your business flow in the application while narrating it aloud, and the test would be written before your eyes in business micro-phrases, using your words. It would be a fork of neither Robot Framework nor Playwright, but an orchestrator marrying the keyword-driven approach of the former with the engine and user-facing locators of the latter. Status as of 6 October 2026: six specifications written on 12 August 2026, no code, no prototype and no demonstration. The voice mode awaits a quantified criterion (over 85% correct steps, under 2 s latency) that has not yet been measured.

No, by design intent. The visible language would consist of business micro-phrases created on the fly with the demonstrator's words ('Approve order', 'Log in as buyer'), never code or tool syntax. A visual studio is planned for assembling and editing keywords, while technical profiles would keep a dev mode to edit the source YAML file directly. None of this is built yet: CabraFlow is at the specification stage.

It is a design goal, not yet a measured result. The language would contain no CSS or XPath: targets would be resolved through the accessibility tree (accessible role and name, Playwright's getByRole locators), and the test would interact with the page like a human user. If an engineering update changes the HTML while preserving semantic roles, the test should hold.

No, by design. The test would be a human-readable, versionable YAML file, planned to be replayed on three targets: the native runner, a Playwright export (.spec.ts) and a Robot Framework export (.robot), plus an ISTQB documentation export for formal sign-off and audits. The exports are planned to be regenerated from the YAML. None of this exists yet: CabraFlow is in design.