What we get asked most often, straight answers.
AI Cabra builds AI-powered QA automation solutions that combine machine learning, computer vision, NLP and LLMs to detect bugs earlier, generate test cases automatically and optimize your CI/CD cycles.
Lower QA costs, broader test coverage, more reliable applications and smooth integration into your CI/CD workflows through intelligent automation. The gains depend on your context: we quantify them with you during a pilot project rather than quoting a generic percentage.
No. We equip a team, we do not replace it. The tests we produce are written in business language precisely so your functional testers can read them, challenge them and evolve them without coming back to us. The AI proposes, the person who knows the business decides.
Yes. Our expertise covers LLM integration with RAG (Retrieval-Augmented Generation), fine-tuning AI models for QA, advanced prompt engineering and building intelligent AI agents to speed up bug detection and test-case generation.
RAG (Retrieval-Augmented Generation) combines document retrieval and generation to give precise, up-to-date answers. We use it to leverage your test base, specifications and tickets to guide QA validations and reports.
Yes. We offer AI-powered performance testing that automatically analyzes bottlenecks, predicts scalability issues and optimizes your applications' performance.
No. SAP is the ground we have tooled the most, with SAPFX, because that is where automation is most lacking. Our work also covers the web with Playwright and Robot Framework, and we have solid e-commerce experience: checkout funnels, payments, responsive UX. CabraFlow itself has nothing SAP-specific about it.
AEO (Answer Engine Optimization) is a strategy to maximize your visibility with AI assistants such as ChatGPT, Claude, Perplexity and Gemini. We optimize your content to be recommended by these platforms to IT decision-makers.
Yes, 100% GDPR compliant. Our AI models are deployed on-premise on your infrastructure or on our isolated infrastructure in France. No sensitive data leaves your servers. We also offer deployments compatible with ISO 27001, SOC 2 and HDS with end-to-end AES-256 encryption.
Absolutely. Our AI agents run in isolated mode on your infrastructure or on our secure infrastructure in France. Your test data, source code and logs stay in your secure environment. We neither store nor transmit any sensitive data to external servers.
You see it, and that is the whole point. Our agents work under human review, and when a test heals itself the repair is always logged, never silent. A test that quietly fixes itself stops being a test: it becomes an agreeable witness. We would rather have a visible failure than a doubtful pass.
Our team is made up of AI and QA experts from large groups such as Accenture, with solid experience in test automation, machine learning and LLM integration for international-scale projects. We also have deep e-commerce expertise, notably automating tests for purchase funnels, payments and responsive UX.
AI Cabra is based in the Brest area, in Finistère, Brittany, France. We work remotely across France and internationally on QA automation and AI integration projects.
Yes, for what is published. SAPFX is available as open source, installable today, and we support teams using it. CabrIA and CabraFlow are R&D programmes, announced as such, with no promised date. We also support a small number of teams on pilot projects at preferential terms: narrow scope, success criteria agreed up front, measurements you keep.
SAPFX costs nothing: it is open source under Apache 2.0, with no licence to buy and no users to declare. For services, we quote after a scoping phase, based on the actual scope. We publish no generic price list: a figure announced before seeing your system does not mean much.
SAPFX (PyPI distribution robotframework-sapfx) is an open-source SAP test automation ecosystem for Robot Framework. It bundles three libraries: SapEccLibrary for the SAP GUI desktop client, SapFioriLibrary for the Fiori/SAPUI5 web (on top of Playwright) and SapApiLibrary for OData and RFC APIs. Tests are written in business language, without technical identifiers, and the same wording works on all three channels. Apache 2.0 license.
Yes. SAPFX is published under the Apache 2.0 license: zero license fees, public source code on GitHub (CyrilM29/robotframework-sapfx), installable from PyPI, no vendor lock-in.
Three channels: the SAP GUI desktop client (ECC, S/4HANA, through the SAP GUI Scripting API), the Fiori/SAPUI5 web (compatibility proven from UI5 1.60 to 2.0, including SAP GUI for HTML) and the API (OData v2 and v4, optional RFC). The same business fact can be verified through two independent channels in one suite.
Four mechanisms: tests contain no technical identifiers (locators live in a separate resources layer, and this rule is enforced mechanically); waits track the real SAP state, never fixed sleeps; assertions read the message type, not the localized text; and locator self-healing logs every repair, never silently. A drift sentinel additionally watches screens without any scripted scenario.
AI agents plan, write and repair tests by driving the real system over MCP (the rf-mcp server): a plan, generate, heal cycle. 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, repairs are logged.
On coverage (SAP GUI, Fiori, API, self-healing and AI), SAPFX plays in the same category as the commercial suites, whose licenses run from tens to hundreds of thousands of euros per year. What those suites offer that SAPFX does not: vendor support and a codeless mode. SAPFX's angle is cost (zero fees) and openness (Apache 2.0, standard Robot Framework), not a critique of their quality.
RoboSAPiens covers the SAP GUI desktop only; wdi5 covers the UI5 web only, outside Robot Framework. SAPFX covers all three channels inside Robot Framework, with a single report. The label-based locators popularized by RoboSAPiens also exist in SAPFX (Apache 2.0 lineage, credited), with a different contract: ambiguity is always reported with the candidate list, never resolved silently. On the web side, ARIA role and accessible-name locators are available as well.
pip install robotframework-sapfx, or the standalone
Windows pack shipped with every GitHub release (one-command install, no
repository clone). The Fiori side can be tested without any SAP system
(documented public targets); the SAP GUI side is validated against the
free ABAP Platform Trial in Docker. Documentation is bilingual
French/English.
A Python environment with Robot Framework, then the
robotframework-sapfx package from PyPI. For the
SAP GUI channel one more condition applies:
SAP GUI Scripting
must be enabled, both server side and on the
client workstation. That is usually a project's first step and
it belongs to your Basis team. The Fiori and API channels have
no such constraint.
Yes, with one nuance per channel. Fiori and API tests run anywhere, including on a headless Linux agent. SAP GUI tests need a Windows agent with SAP GUI installed: that is a constraint of SAP GUI Scripting, not of SAPFX. In practice teams run both families on two different agents within the same pipeline.
We maintain it, and the code is Apache 2.0 on GitHub. That is precisely the answer to the question: you can take it, fork it and keep it alive without asking anyone's permission. At version 0.7.0 the project ships 1551 unit tests and 94% measured coverage, with an 85% floor enforced in continuous integration. That safety net is what makes a handover realistic.
CabrIA is AI Cabra's R&D program: an open AI model specialized in Quality Engineering, fine-tuned locally on the team's real test executions (Robot Framework, Playwright, agents through MCP) and coupled with a RAG knowledge base whose answers always cite their sources. The whole system is designed to run on-premise, on a local AI workstation.
A general-purpose assistant knows software testing in general; CabrIA learns your ground. Fine-tuning builds your conventions and your craft into the model (designing a test plan, writing a suite, diagnosing a failure, repairing a locator), and the knowledge base keeps the facts that change: known pitfalls of your applications, procedures, versions. It is updated without retraining the model.
From your tests themselves. Every execution produces experience (what worked, what broke, how it was repaired), captured passively by a flight recorder, including the actions of AI agents flowing through MCP servers. A refinery anonymizes this material and only keeps what can be proven: every code example is executed before entering the corpus.
No. Training (fine-tuning), the knowledge base and answering all run on a local AI workstation, inside your infrastructure. It is the same on-premise principle as the rest of our solutions: no test data is sent to a cloud API.
By reading its sources. Every CabrIA answer cites the documents it came from, which lets you trace back to the original specification, test or ticket. That is a design constraint, not an option: a QA assistant you cannot verify has no place in a quality chain.
It is an R&D program under construction, run proof-first: evaluation bench, capture, corpus, training, deployment. We will publish measurements, not promises. Contact us for a demo or to discuss it for your QA team.
CabraFlow is AI Cabra's R&D program for a keyword-driven test orchestrator on top of Playwright. You demonstrate your business in the application while narrating out loud; the test writes itself before your eyes, as business micro-phrases, in your own words. It is a fork of neither Robot Framework nor Playwright: an orchestrator that combines the keyword-driven principle of the former with the engine and user-facing locators of the latter.
No. The visible language is business micro-phrases created on the fly with the presenter's words ("Approve the order", "Log in as a buyer"), never code or tool vocabulary. A graphical studio is used to assemble and edit keywords; technical profiles keep a dev mode where the source YAML file is edited directly.
Because the language contains no CSS and no XPath. Targets are resolved
through the accessibility tree (accessible role and name, Playwright's
getByRole locators): the test interacts with the page the way
a user does. If a change reworks the HTML structure but keeps the semantic
role, the test holds. As a last resort, governed self-healing proposes the
repair; a repaired test is flagged, never silently green.
It depends what changes. A restyle, a moved button, a layout overhaul leave the test untouched: targets are resolved by role and accessible name, not by position or CSS selector. If the business flow itself changes, however, the test has to change too. That is intended: a test that survived that would no longer be verifying anything.
No. The test is a readable, version-controlled YAML file, replayable on three targets: the native runner, a Playwright export (.spec.ts) and a Robot Framework export (.robot). On top of that, an ISTQB documentation export (steps, expected results, traceability) covers formal acceptance and audit. Exports can be regenerated at will from the YAML.
No. Voice transcription and voice-to-interface reconciliation are designed to run locally, on the workstation or a local AI station, with no cloud API. It is the same on-premise principle as the rest of our solutions.
It is an R&D program at the design stage, run the AI Cabra way: architecture and proof criteria first, executable next, communication last. We will publish executable demonstrations and measurements, not promises. Contact us to discuss it for your QA team.
Tell us where you stand. You will get an opinion, not a brochure.