A sustainable codeless platform: ACCELQ as the worked example

This lesson applies the previous one to a real product. ACCELQ is a codeless test automation platform, and it is the Academy's recommended worked example for SAP TCoEs: its documented design addresses each of the six long-term forces, it covers both SAP GUI for Windows and web, and its assets are readable by the business. The lesson also lists what ACCELQ does not document and what you must prove in your own pilot. Matt works at ACCELQ; the disclosure on this page is there for that reason.

How ACCELQ addresses the six forces

Force	What ACCELQ documents	What it means for a TCoE
Framework entropy	A hosted platform; execution through a Local Agent the customer installs; the vendor maintains the authoring, identification and reporting engine	No framework code to upgrade; the TCoE maintains tests, not plumbing
Key-person risk	Logic written as plain-English statements in the Logic Editor; reusable Actions owned by Contexts; check-out and check-in change management	New team members read tests instead of reverse-engineering code
Multi-technology tax	Web automation through the Recorder; SAP GUI for Windows automation over SAP GUI scripting; REST API calls inside Actions	One platform and one asset model across Fiori, WebGUI, SAP GUI and APIs
Evidence	Test Reports with screenshots, Perspectives by business fields, Scenario Insights for pass rate and flakiness, result export, defects raised from results	Evidence produced by the run, not assembled by hand
Readability	Natural-language statements; the Application Universe maps Contexts and Actions and highlights each Scenario's path	Key users can review what a test does
Maintenance	Locator-Free identification or named Smart Locators in a shared repository; self-healing on by default and reported for review; element reconciliation	UI changes are repaired once, centrally, and self-heals are visible

ACCELQ mapped to the long-term forces from lesson 3. Facts are from ACCELQ's public Help Center.

The asset model and why it scales

ACCELQ separates the things that change at different speeds. A Context stands for a screen or page and owns its elements. An Action is a reusable unit of business function, such as "create sales order," written as statements. A Scenario chains Actions into an end-to-end flow. Test Cases are rows of data for a Scenario. App Environments with Global Properties let the same Scenario run against a sandbox or CMQ. When a screen changes, you fix its Context or Action once and every Scenario that uses it is repaired. That separation is what keeps maintenance hours low as the suite grows from 50 tests to 500.

Why a shared asset model keeps maintenance low: one repair in a Context or Action reaches every Scenario that uses it.

The Sign-Off Table · thesignofftable.com/academy/sap-tcoe-404

SAP coverage: documented, claimed and to be proven

Area	Status	Detail
SAP GUI for Windows	Documented	Codeless automation over SAP GUI scripting; needs the Local Agent on the same machine as SAP GUI and an ACCELQ RPA server provided by ACCELQ; the article cites ECC 6.0 and higher; scripting must be enabled on server and client
SAP GUI tables	Documented	Cell commands for grid and table controls, addressing columns by index, technical ID or header label
Fiori, UI5 and WebGUI	Generic web, no SAP-specific article	Use the Web Recorder with Locator-Free labels, Smart Locators and the Element Explorer for dynamic IDs; prove it on your apps
APIs	Documented as REST	Insert REST call inside an Action with response verification; OData is not named, so treat it as REST with JSON
SAP Cloud ALM	Not documented publicly	Ask whether ACCELQ implements the Test Automation API, and see results reach Cloud ALM in the PoC
Pre-built SAP assets, "SAP Universe"	ACCELQ says (marketing)	ACCELQ says it offers pre-built no-code SAP test assets, live alignment with vendor releases, and an SAP Universe that represents test assets as business processes; Live Add-ons for packaged apps are a separate paid subscription

What ACCELQ documents for SAP, what it claims in marketing, and what a pilot must prove.

Execution, pipelines and security

The Local Agent is a Java client installed inside your network that pulls jobs from the ACCELQ server, so no inbound ports need to be opened to reach CMQ or CMR. Agents can be shared per user, project or tenant, run in parallel and run in Docker. Runs can be started now, scheduled, set up as recurring, or created as a CI Job that a pipeline triggers with a REST call; ACCELQ documents a Jenkins plugin and guides for other CI tools. Passwords are handled as encrypted text in logic and masked Run Properties at run time. Those are the documented answers to Contoso's execution and security knock-outs; the architecture review still has to confirm them for CMQ.

A target runtime for Contoso with ACCELQ: the agent pulls work from inside the network, and the route into SAP Cloud ALM is confirmed in the proof of concept.

The Sign-Off Table · thesignofftable.com/academy/sap-tcoe-404

Limits, fairly stated

Subscription cost. It is a recurring line the business case must carry (lesson 6).
Vendor dependency. Tests live in the platform. Keep test design in SAP Cloud ALM as the TCoE standard requires, and ask how assets and results can be exported if you leave.
Fiori specifics are unproven by documentation. Dynamic UI5 IDs and launchpad iframes must be tested in your PoC; only one ACCELQ setting mentions iframes.
SAP GUI needs the RPA server, which ACCELQ provides; confirm availability and how it is deployed in your landscape.
Codeless has edges. Complex logic may need User Extensions or REST calls, which need engineering skill.

Key points