Explainer videos · AI in testing, the STDD method, agents on SAP, the SAPFX mindset
Four animated films drawn from real cases on our SAP test bench. They are in English, with a synthetic voice and captions in English, French and Spanish, split into chapters and shipped with their transcript. No camera footage, no third-party player: the videos are served by this site.
AI in test automation: strengths, traps and guardrails
The pros and cons of AI for automated testing, seen from our bench: what an agent does well (explore the real system, check each step, repair, grow the library, cost once), what it risks (confident errors, green but false suites, workarounds, tools that lie, cost, autonomy), and the six guardrails that keep the first without the second. Every example is a real, dated case.
AI in Test Automation · 6 min 43 · synthetic voice, captions burned in. Stedd (the AI agent), MCP (the messenger) and Terra (the real SAP system) fill two columns, what AI brings and what it risks, then balance them with six guardrails. The common thread: AI proposes, the real system decides.
Read the transcript
0:00 · Title
Can an AI agent write and maintain your automated tests? We tried it for real, on live SAP systems. Here is what it does well, where it fails silently, and the guardrails that make it worth it.
0:16 · Meet the cast
Stedd is the AI agent: a language model, with one hat per job: plan, generate, verify, heal. MCP is the messenger: it carries each request to Robot Framework, which drives SAP. Terra is the real SAP system. There are two of them, Terra 2023 and Terra A4H: twins, easy to mix up.
0:39 · The imagined system
One idea runs through this whole film. A language model knows SAP from what it has read: it carries an imagined system in its head. The real system is out there, and it does not always agree. Testing is about that one, never about the imagined one. We will fill two columns: what AI brings, and what it risks. Every example is a real case from our bench, with its date.
1:07 · Plus 1 · it explores
Plus one: an agent can explore the real system. Before any test is written, the planner sends MCP to ask Terra, one assumption at a time. Scenario 4 asked for a Travel app on the Launchpad. Terra answered: 66 apps, 62 intents, none for travel. Over three scenarios, the real system refuted 3, 2 and 5 assumptions of their briefs. None of them made it into a test.
1:36 · Plus 2 · it checks each step
Plus two: every step is played on the real system before it is written. The generator writes only what it saw work. The result is a plain Robot Framework suite, with no AI inside. The AI works at design time; the test runs without it.
1:54 · Plus 3 · it repairs
Plus three: it can repair. On the twelfth of July, we injected a locator drift, blind. The healer read the live screen and scored the closest matches. It patched one line of the resources layer. Tests touched: zero. Re-run: 7 of 7. On the first of September, a public target moved its shell to Web Components, four days after a green run. The campaign fell to 8 of 12. The agents re-explored it, rewrote the spec on what they measured, and the suite came back to 12 of 12.
2:29 · Plus 4 and 5 · it builds, and costs once
Plus four: what the agent cannot do becomes a library capability. Scenario 4 alone delivered six, each with its unit test. Plus five: it costs once. Tokens are spent while designing. A replay is a plain Robot run: zero tokens, from 2 seconds to 5 minutes.
2:49 · What AI brings
What AI brings: it explores, it checks each step, it repairs, it grows the library, and then it steps aside.
2:57 · Minus 1 · confident when wrong
Minus one: it is confident, even when it is wrong. A plan stated that product HT-1000 was present on both of our systems. Checked on the real system: zero results, by API and by RFC. The claim had been written from memory. It happened to this series too: our previous film had a line written from memory. It was false. A check against the sources caught it.
3:25 · Minus 2 · green, and false
Minus two: a green suite can be false. Three generated suites passed: 12 of 12, 13 of 13, and 7 of 7 on two releases. An independent verifier, an agent that only reads, sent all three back: needs human. Eight reservations, then eight, then six. One proved its target on one channel out of three. Another hid three flaws that no run could ever reveal: the suite passed.
3:54 · Minus 3 · it routes around
Minus three: it routes around problems. One suite read a whole grid of 2665 rows instead of filtering, with a note: cause not investigated. The real cause: a remote desktop session drew the screen 2.4 times larger, and label matching broke. The fix belonged in the library.
4:16 · Minus 4 · its tools can lie
Minus four: its tools can lie too. On the seventh of September, a threading issue made our perception return empty screens, reported as a pass. An agent that receives an empty list concludes: no window is open. Wrong, and silent. We fixed it the same evening. And our two Terra systems share the same system ID and host name. Aim at the wrong address, and the agent tests the twin, perfectly green.
4:45 · Minus 5 and 6 · cost and autonomy
Minus five: it is expensive to design. Our measured scenarios cost from 0.69 to over 2.4 million tokens each, and hours of agent time. Just starting an agent costs about 200,000 tokens before any useful work. Refuting the brief costs the most, and is worth the most. Minus six: autonomy. An agent can commit, push or delete. Even the MCP session dumps kept the passwords: they had to be purged.
5:17 · What AI risks
What AI risks: confident errors, green but false suites, workarounds, tools that lie, cost, and too much autonomy.
5:25 · The guardrails
So how do we keep the good and neutralize the traps? With guardrails, not with instructions. One: observe before writing. The spec is confronted with the real system: that is Spec-Test-Driven Development. Two: freeze the result. The AI designs, a deterministic suite runs: zero tokens, and the same verdict every time. Three: an independent verifier, an agent that only reads, hunting weak assertions and green but false runs. Four: scripts that fail loudly. A stale spec, a raw locator, a hidden workaround: refused by a guard, not by a promise. Five: prove the target on every channel, and let a perception that cannot read fail, never pass. Six: a human stays in charge. The healer repairs the vocabulary, never the test, and only a human switches autonomy on.
6:24 · Conclusion
AI in test automation is neither magic nor a gimmick: it is a fast, tireless explorer, as long as the real system has the last word. Use it where checking is cheap, never where being wrong is silent. Thanks for walking with Stedd, MCP and Terra.
The first guardrail, observe before writing, is the heart of the STDD method, told step by step in the next film. The agents in the film are those of rf-test-agents, applied to SAP by SAPFX.
Spec-Test-Driven Development (STDD), explained on a real SAP case
The shared mindset of SAPFX, ODOOFX and rf-test-agents, told on a real SAP case, scenario 4: the spec confronted with the real system before any test, the test derived from the spec, the library the test makes grow, an independent verifier, then the maintenance loop when the system changes.
The STDD film · 8 min 34 · synthetic voice, captions burned in. A real SAP case, scenario 4 (a RAP travel created through Fiori Elements on ABAP Platform 2023), told link by link by Stedd (the agents), MCP (the messenger) and Terra (the real system).
Read the transcript
0:00 · Title
A short story about testing SAP systems, told by three characters: an agent, a messenger, a real system. And about a mindset, Spec-Test-Driven Development (STDD): what we test is first observed on the real system.
0:17 · Meet the cast
Stedd is the AI agent. One hat per job: plan, generate, verify, heal. MCP is the messenger: requests out to Robot Framework, answers back. Terra is the real SAP system. Two of them: Terra 2023, our target, and Terra A4H, its twin.
0:36 · The usual way
Most test automation starts from what we assume the system does: a document, a memory, a screenshot. The test is written from the assumption, without looking at the system. It runs. It turns green. But the real system was never asked: the tile does not exist, the app lives elsewhere. Green, and false.
1:00 · From TDD to STDD
You may know TDD: red, green, refactor. The test comes first, the code follows. STDD applies the same logic one brick earlier: the spec comes first. In theory, a spec is green by default: nobody tests it. STDD puts it to the test on the real system: red where it was wrong, green once observed. Only then comes the test.
1:25 · Three links
STDD is a chain of three links. Each one drives the next, and each one is checked by a script. 1 · The spec, written in human language, then confronted with the real system by an agent, before any code. 2 · The test, derived from the spec as it was observed, and sealed with the spec's fingerprint. 3 · The library, developed from what the test needs: never a workaround hidden in the test. Three scripts: agent_contract.py, check_spec_sync.py, check_conventions.py. They fail loudly.
1:59 · A real case: scenario 4
A real case: scenario 4, on Terra 2023 (ABAP Platform 2023): create a travel with a booking, in Fiori. The spec is a plain-language brief: seven lines, no code. Any form works: a goal, a user story, a BDD scenario… This one assumes two things: a Launchpad tile opens the app, and the target is the cap-sflight demo.
2:25 · Link 1 · the spec meets the real system
Link 1. The planner agent, an LLM, confronts the brief with the live system, before writing a single test. It does not guess. It sends MCP: Robot Framework drives SAP for real, the LLM only reads the answers. Assumption 1, a Launchpad tile: 62 intents checked on Terra 2023. None opens a travel app. Refuted. Assumption 2, cap-sflight: a local CAP app on port 4004. Not this target. Here, the app is RAP: /DMO/UI_TRAVEL_D_D. The real app exists anyway: 4,136 travels, and the server generates a Fiori Elements preview… behind an HTTP 500. The fix is read in the server's own source code: the address is obfuscated, +20 per character. Decoded: HTTP 200. Before writing anything: can we undo it? Discarding a draft needs If-Match. Tried, then proven: reversible. Side by side: the brief as assumed, the spec as observed on Terra 2023, line by line. No tile, another target, a required currency the screen hides, an ID that gets reassigned: none of it could be guessed. 12 deviations in all, each backed by a measurement. A human reviews them before anything is generated. The spec as observed, 12 deviations from the brief included, is written down, sealed with a sha256 and reviewed by a human. It becomes the source of truth. To remember: the spec is observed, not assumed. The surprises come before the tests, not after.
4:17 · Link 2 · the test, derived from the spec
Link 2. The generator agent turns the observed spec into a Robot Framework suite, in business vocabulary. Every step is executed on Terra 2023 first, through MCP, and written only once it works. No guessed locator. The suite carries the spec's fingerprint, its sha256: the test knows exactly which spec it was derived from. Change the spec without regenerating, and check_spec_sync.py refuses the run. Regenerated, reviewed: in phase again. A script, not a promise. To remember: nothing is written that has not run first, and the suite stays sealed to its spec.
5:02 · Link 3 · the test drives the library
Link 3. Sometimes the test needs something the library cannot do yet: a date format, a missing header… …then the gap becomes a keyword in the library, with its unit test. Never a workaround in the test: check_conventions.py watches. Six capabilities, each with its unit test: dates typed in the field's own format, If-Match, the release read over HTTP, the preview address… The library ships to PyPI, as robotframework-sapfx. The next project gets all six for free. To remember: the test drives the library, and every gap closed there helps the next project.
5:53 · An independent verifier
Stedd changes hats. The verifier reads the plan, the suite and the evidence. It runs nothing. Its first verdict on the green suite: not verified. 13 reserves, 3 of them blocking. All 13 fixed, then a counter-review: needs human, 7 more points. Fixed too. Every guard must be seen refusing. First, the reference on Terra 2023: release 758, 58 services. Then the suite is pointed at Terra A4H, on purpose: same system ID, same host name as Terra 2023. Compared: 754 ≠ 758, 38 ≠ 58, no UI5 runtime. Every guard refuses. Seen, not assumed. Second provocation: a draft planted by hand on Terra 2023. The guard spared it, the cleanup deleted it. Found, fixed, replayed. To remember: a guard that nobody has seen refuse proves nothing.
6:58 · Result
Result: 7 tests out of 7 on Terra 2023. Every travel created is deleted, and proven gone, entity by entity. Generating cost 1.67 M LLM tokens, once. Replaying costs zero tokens: plain Python, under five minutes.
7:19 · When the system changes
A real case, 1 September: the public OpenUI5 Demo Kit changed its shell overnight. Not one line of our repo moved. The campaign drops to 8 of 12. The healer's diagnosis: not a locator, the flow itself changed. The spec is marked STALE. The planner goes back to the real target, rewrites the spec on what it measures, and the suite follows: 12 of 12, sealed again. The other branch, tested blind on Terra A4H: a locator drift injected on purpose. The healer reads the live screen… …and patches one line of resources/. Tests touched: zero. Re-run: 7 of 7. STDD is a loop, not a pipeline. The healer repairs resources/, never the test. A changed flow goes back to the spec, and the suite follows it.
8:15 · Conclusion
Spec first, in human language. Test from the spec. Library from the test. Each link guarded by a script. Observed, derived, guarded, and kept alive when the system changes. Thanks for walking with Stedd, MCP and Terra.
Definition in the glossary, the difference with TDD in the FAQ, and the full method in rf-test-agents. The next film shows the machinery that lets these agents drive SAP.
How AI agents drive SAP: MCP, rf-mcp, the SAPFX plugins and qa-brain
How SAPFX plugs AI agents into real SAP systems, one layer at a time: the MCP protocol, the generic rf-mcp server and its three SAP plugins (one per channel: SAP GUI, Fiori, API), the thin sapfx-mcp overlay and its compatibility guard, qa-brain, the team's QA memory served by a second MCP server, the keys each agent holds, the lessons learned live, then the key point: MCP is for design time, and the suite it leaves behind replays with no agent and no tokens.
How AI agents drive SAP · 8 min 20 · synthetic voice, captions burned in. Stedd (the AI agent), MCP (the messenger), Terra (the real SAP system) and qa-brain (the team memory) follow a real round trip on SE16, from the protocol down to the SAP screen. The common thread: the agent speaks MCP, the plugins speak SAP, the memory remembers, and the real system decides.
Read the transcript
0:00 · Title
An AI agent cannot click a SAP screen on its own. It needs a protocol, a test engine, and something that speaks SAP. This is how SAPFX plugs AI agents into real SAP systems: MCP, rf-mcp, three plugins, and a shared memory.
0:20 · Meet the cast
Stedd is the AI agent: a language model with one hat per job: plan, generate, verify, heal. MCP is the messenger: the Model Context Protocol, the standard way for an agent to call tools. Terra is the real SAP system. Two of them on our bench: Terra 2023 and Terra A4H. qa-brain is the team memory: specs, keywords and lessons from past incidents, searchable by the agents.
0:49 · The gap
SAP has three doors: the SAP GUI desktop client, Fiori web apps, and OData and RFC services, with no screen at all. A generic MCP server for Robot Framework already exists: rf-mcp. It discovers keywords, runs them live, and writes test suites. But its locator guidance knows Browser, Selenium and Appium. UI5 controls, the WebGUI, the SAP GUI screen: nothing.
1:19 · Compose above
So we did not write a new MCP server. We compose above rf-mcp, with three plugins: one per SAP channel. rf-mcp keeps the generic work. The plugins add what only SAP needs, and the SAPFX libraries do the real driving. The same rule as the rest of the project: do not merge the paradigms at the technical layer. Unify above.
1:47 · Three hooks
Each plugin clicks into rf-mcp through three hooks, registered as Python entry points: no fork, no patch. Hook one, the keyword map: Run Transaction goes to the library for SAP GUI, Click Ui5 Control to the one for Fiori. Hook two, the hints: address UI5 controls, never DOM ids; judge a message by its type, never its translated text; never sleep. Hook three, the state provider: the live SAP screen becomes the page source of the session. The agent sees before it acts.
2:25 · One round trip
Let us follow one round trip. Stedd asks MCP to run SE16 on Terra A4H. Robot Framework runs it, and a green ticket comes back. Then Stedd looks: the state provider sends back the real screen, one line per control, editable fields marked with a star. It opens table T000, sets the maximum number of hits to 300, and looks again. This time only what changed comes back: a diff of 290 bytes instead of 11,945. The context of the agent is spared on every turn. And nothing fragile crosses the boundary: keywords return plain text and dictionaries, never a live COM object.
3:17 · Three channels
Three channels, three plugins. On the SAP GUI, the ECC plugin serves the screen signature we just saw. On Fiori, rf-mcp asks the Browser library for the page, so the plugin steers the agent to a keyword: Get Ui5 Page Tree, the UI5 control tree. The API channel has no screen. Its plugin says so honestly, and serves the real channel state instead: open sessions, never credentials. Both screen paths were replayed end to end through rf-mcp: Fiori, 8 out of 8, and SAP GUI, 9 out of 9 against a live system.
3:58 · The overlay: sapfx-mcp
Some things the plugin contract cannot express. So a thin layer, sapfx-mcp, mounts rf-mcp unchanged and adds three tools. sapfx_state serves our perception directly: the diff by default, and what rf-mcp never asks for, like an error popup still open. sapfx_screenshot sends a real image, with numbered boxes on every target: the agent reads a number, and acts on a verified id. sapfx_reload reloads the plugins without restarting the server. The rule: every wiring rf-mcp accepts upstream makes this layer smaller. It must never grow into a fork.
4:43 · The guard
At startup, a compatibility guard checks the rf-mcp version and probes every internal anchor the layer touches. On the twenty-sixth of September, rf-mcp 0.36 came out. Two days later our CI turned red, although nobody had touched the overlay. That was the guard, refusing a version it had not validated. We replayed both paths on it, then widened the window. Loud, never silent.
5:12 · qa-brain: the team memory
Now the second MCP server: qa-brain. A search engine over the QA memory of the team, running on our own machines. It indexes Robot Framework keywords, specs, docs, and lessons written after real incidents: 1,383 passages, on the twenty-ninth of September. Before a judgment call, the agent asks. Here the planner asks how to find a field on an SE16 selection screen, where fields are numbered by position. qa-brain answers with sources: the library keyword that derives those fields, and the spec that first warned about them. Three rules. The live system decides: a passage is a lead, never a proof. The source is cited. And qa-brain never blocks the work. The point: a lesson someone already paid for, on a real incident, is not paid for twice.
6:09 · Who holds which key
Each agent gets only the keys it needs. The planner, the generator and the healer drive SAP through rf-mcp. The verifier has no SAP tool at all: it only reads. That is what makes its review independent. All five can ask qa-brain, down to the ISTQB designer, who works offline. On top, a permission hook lets reads through and asks before the rest. Only a human switches autonomy on.
6:47 · Learned live
Some lessons were paid for live. rf-mcp runs keywords off the main thread, and SAP GUI scripting is COM: each thread must initialize it first. On the seventh of September, a look from the wrong thread came back empty, and green. Now it fails, names the cause, and re-attaches. The server also keeps the library code it loaded at startup. When our code changes on disk, the state answers carry a stale code warning. And one rule of hygiene: one live SAP GUI session per server, closed at the end, even after a failure.
7:27 · Design time, run time
Here is the key point. MCP is for design time: exploring, checking each step live, repairing, remembering. What it leaves behind is a plain Robot Framework suite. It replays with the robot command: no agent, no MCP, zero tokens.
7:49 · Recap
Agent, protocol, engine, plugins, libraries, system, and a shared memory: each layer does one job.
8:01 · Conclusion
The agent speaks MCP. The plugins speak SAP. The memory remembers. And the real system decides. Open source, built on rf-mcp. Thanks for flying with Stedd, MCP, Terra and qa-brain.
The plugins and the sapfx-mcp overlay are part of SAPFX; the agents are those of rf-test-agents, and qa-brain is the local RAG of CabrIA. The figures quoted in the film date from its making, on 29 September 2026; on 9 October 2026, qa-brain indexes 4,119 passages. The next film sums it all up in seven principles.
The SAPFX mindset: seven principles, a toolbox, what it changes
Why SAPFX is built the way it is, in seven principles backed by real cases: unify above the SAP channels, let the real system decide, never be green and false, see before acting, AI designs and Robot replays, a gap becomes a capability, rules enforced and not just stated. Then the complete toolbox, and what changes in practice, including what SAPFX does not have (vendor support, graphical editor).
The SAPFX mindset · 11 min 11 · synthetic voice, captions burned in. The characters of the earlier films (Stedd, MCP, Terra, qa-brain) welcome three newcomers: You (the human who decides), RF (Robot Framework at run time) and Gate (the mechanical guards). Each principle ends with a “Remember” card.
Read the transcript
0:00 · Title
Testing SAP well is not about one tool. It is a way of working, and this film is about the mindset behind SAPFX. What we build, how we build it, and what it changes, told by the cast of our earlier films and three newcomers.
0:18 · Meet the cast
Four regulars from our earlier films: Stedd, the AI agent, MCP, its messenger, Terra, the real SAP system, and qa-brain, the team memory. Stedd wears one hat per job: plan, generate, verify, heal. And Terra has a twin on our bench: Terra 2023 and Terra A4H. Three newcomers. You: the person who decides. You write the spec in plain language, and you review what comes back. RF is Robot Framework at run time. It replays what was written, exactly, as often as you like: no agent, no model, zero tokens. And Gate: the scripts that say no. No opinion, no mood: the same answer every time, green or red.
1:04 · The SAP testing problem
SAP is not one application. It has a desktop client, Fiori web apps, SAP GUI in a browser, and OData and RFC services. Tests written against it break for nothing: a renamed id, a translated message, a fixed wait that was one second too short. Worse, some pass when they should not. A test can be green and false: it looked at an empty grid, or at the wrong system. The market has three families. Commercial suites: complete, supported, licensed. Tools from SAP itself: included, but limited. And open source: free and open, historically one channel at a time. SAPFX belongs here, and brings what was missing: all three channels. It rests on seven principles. Here they are, one by one.
1:55 · Principle 1 · Unify above
Principle one: unify above. Tests speak one business vocabulary. Underneath, three libraries each speak one SAP language. SapEccLibrary drives the desktop client through its scripting API. SapFioriLibrary drives the browser, with five ways to find a control. SapApiLibrary speaks OData and RFC. And shared logic, tested without any SAP system, sits under all three. The same words on every channel: count table entries on the screen, count business entities over OData, count business records over RFC. So one fact can be checked twice: 205 products on the screen, 205 through OData. Three channels even agree on one product's price. Remember: write the test once, in business words. The channel underneath is a detail, not a rewrite.
2:51 · Principle 2 · The real system decides
Principle two: the real system decides. You write the spec in plain language: a goal, a user story, a BDD scenario, an old test. The planner confronts it with Terra, live. What the system refutes turns red: three, two, then five wrong assumptions on three recent scenarios. What survives is the observed spec. You review it, and it is sealed: the test is derived from it, then the library from the test. Change the spec without regenerating the suite, and Gate refuses: check spec sync compares a fingerprint, every time. It is the logic of test-driven development, one brick earlier: a spec nobody confronted is green by default, never by proof. Remember: a spec nobody confronted is green by default, not by proof. The observed spec drives the test.
3:44 · Principle 3 · Never green and false
Principle three: never green and false. A test that cannot prove what it saw must fail, and fail loudly. Assertions read the message type, never the translated text. And tests wait for SAP to be idle, never a fixed sleep. Our two systems share the same ID and the same host name. Only the release tells them apart, so our campaigns prove their target first. Tables load lazily. One grid returned 1,639 rows, only 137 filled. A web grid sent 200 rows of 2,000. A Fiori table, 30 of 4,133. Every row looked perfect. So each extraction is checked against the total the table declares, and refused when they differ. And when perception cannot read the screen, it now fails and names the cause, instead of an empty, green answer. Remember: a test that cannot see must fail, loudly. Targets are proven, totals are declared.
4:53 · Principle 4 · See before acting
Principle four: see before acting. An agent never acts on what it remembers of a screen, only on what it perceives now. The libraries read the live screen as text: every field, its label, its value. Or as a numbered map, so the agent says: fill number one. After an action, only the difference comes back: 290 bytes, instead of 11,945 for the whole screen. Locators can be human: fill the field labelled Table Name. The label must point at one field only, or the step fails. When an id drifts, the library suggests the closest match, scored, and logs every repair. The healer patches the shared layer, never the test. Remember: the agent acts on what it perceives, not on what it remembers. Every repair is logged, never silent.
5:50 · Principle 5 · AI designs, Robot replays
Principle five: AI designs, Robot replays. At design time, agents work through MCP, on the real system. The planner explores, the generator runs each step before writing it, an independent verifier only reads, and the healer repairs. They consult qa-brain before a judgement call. And only You can switch on autonomous mode: a switch for humans only. What the agents leave behind is a plain Robot Framework suite. RF replays it as often as you like, with no agent and no model: zero tokens. Tokens are paid once, at design: 3.8 million for our Business Partner scenario. Its replay takes thirty seconds, and zero tokens. RF also runs a drift sentinel: watched screens compared with their reference, no test written. It reports a change, and never calls it a bug. Remember: tokens are paid once, at design time. What remains is plain Robot Framework, replayed for free.
6:59 · Principle 6 · A gap becomes a capability
Principle six: a gap becomes a capability. When a campaign hits a wall on a real system, the fix does not stay in the test. It becomes a keyword of the library, with its unit test, its documentation page and its changelog entry. Then it ships on PyPI, to everyone. On the seventh of September, one campaign listed eighteen things our desktop library could not do yet, each reproduced by a test. The fixes shipped that same evening. Replayed as it was, the register turned red eighteen times, naming each new capability. That is how we know it measures. Remember: a wall found on a real system becomes a library keyword. The fix ships to everyone, never hidden in a test.
7:51 · Principle 7 · Rules enforced, not stated
Principle seven: rules are enforced, not stated. A rule nobody checks is only a wish. Gate stops a suite older than its spec, a raw SAP id in a test, a code file over 500 lines, a figure in our communication the code does not back. It stops coverage under 85 percent, and any private file on its way to the public repository. They run in CI, and most of them after every edit too. Several of these rules were born from a real incident. Written into a script, they cannot be forgotten, and they never argue: green, or red. Remember: a rule nobody enforces is a wish. Here, scripts say no, the same way every time.
8:46 · The toolbox
Here is the whole toolbox. Three libraries and their shared core, on PyPI, under Apache 2.0. Two recorders, desktop and web: You click through a flow, and get a Robot suite, business keywords, a draft spec, an ISTQB test case, a report. Five agents and a skill. rf-mcp with three SAP plugins and its overlay, and qa-brain, the team memory. A drift sentinel, visual baselines, healing telemetry, a security posture check, and table extraction to five formats, from CSV to Parquet. And for the workstation, a Windows pack that installs in one command, with documentation in English and French.
9:39 · What it changes
So what does this change? First, it is open: Apache 2.0, no licence fee, no lock-in, and the library source is open to read. One business vocabulary for the desktop, the web and the API channel, where open source tools historically covered one channel each. AI where it helps, at design time, and deterministic replay at run time. And the spec is observed on the real system, not assumed. Proof, not promises: 321 scenarios passed live on four real SAP systems, and 2,560 unit tests with 94 percent coverage. What it does not have: vendor support and a codeless mode. Commercial suites offer both, and for some teams they matter. Our place on the map: the capabilities of a commercial suite, at the cost of open source.
10:39 · Conclusion
Seven principles: unify above, the real system decides, never green and false, see before acting, AI designs and Robot replays, a gap becomes a capability, and rules are enforced, not stated. You decide what matters. The agents do the legwork. RF replays, for free. And whatever anyone assumes, the real system decides.
It is the synthesis of the three previous films: AI in testing, the STDD method and agents driving SAP. The libraries are those of SAPFX, the agents those of rf-test-agents. The figures quoted in the film date from its making, on 30 September 2026; at version 0.8.5 of 13 October 2026, SAPFX counts 462 scenarios passed live on four real SAP systems, 3,959 unit tests and 95% code coverage.
Let's discuss your project
SAP automation, local AI or software quality: talk to our technical team.
- A technical exchange, not a sales pitch
- Your data stays in France