01The organization
Picture a manufacturer of industrial pumps with plants in three countries. Sales orders, purchasing, goods movements and invoicing run on SAP S/4HANA, and most users work in Fiori apps.
Transports move from development to quality to production every week. The regression pack is a spreadsheet that key users are meant to work through between their day jobs, and the change board signs off on trust.
SAP regression is a people problem as much as a tooling problem. The people who know order-to-cash and procure-to-pay have day jobs, and every transport asks for a little more of their time. Tests they can read and write themselves are what turn regression from a favor into a routine.
02Business objectives
- Run core process regression before and after each transport
- Let process owners build and maintain the tests
- Tell a configuration change from a real defect quickly
- Give the change board evidence, not a spreadsheet
03Testing challenges
Processes cross modules
Order-to-cash touches sales, availability, delivery, billing and finance, owned by different teams.
Key users are busy
The people who know the processes have day jobs, so testing gets squeezed.
Fiori changes
App updates move fields and tiles, which breaks recorded scripts.
Sign-off without proof
The change board approves transports without a record of what was tested.
04Before and after
How the testing work would change once the journeys run in Robonito.
- Regression pack
- Today:A shared spreadsheet worked through by busy key users.
- With Robonito:Process tests that run before and after each transport.
- Authoring
- Today:Specialists needed to change any automated test.
- With Robonito:Process owners write and update plain-language tests.
- Failures
- Today:Hours spent working out whether a failure is configuration or a defect.
- With Robonito:AI root cause, video and trace for each failed step.
- Sign-off
- Today:The change board approves on trust.
- With Robonito:The change board sees run records for each transport.
05How Robonito would test it
- 1
Process tests in plain language
Process owners describe order-to-cash and procure-to-pay as plain-language steps in Fiori.
- 2
One test per business process
Each process runs as a single test across the Fiori apps it touches, with checks at each step.
- 3
Before and after each transport
Suites run from Azure DevOps in the quality system before and after each transport import.
- 4
Root cause per step
When a step fails, the AI root cause, video and trace show whether it's configuration or a defect.
06Test scenarios, in plain language
Tests you'd write in Robonito on day one. Each one is typed as written; the agent works through the app and saves the steps.
- Order-to-cashCreate a sales order for a known customer with two items in Fiori and confirm the availability check and outbound delivery.
- BillingPost goods issue for the delivery, create the billing document, and confirm the receivable in the customer's account.
- Procure-to-payPost a goods receipt for a purchase order and confirm the stock quantity in the stock overview app.
- Invoice matchEnter a supplier invoice with a price variance above tolerance and confirm it is blocked for payment.
- ApprovalsApprove a purchase requisition as the cost-center manager in My Inbox and confirm the purchase order is created.
07What the pilot measures
No made-up numbers: a pilot measures these against your current baseline, on your own app.
Regression per transport
Hours to run the covered processes for each transport, against today's spreadsheet.
Key-user time
Hours returned to key users per release cycle.
Triage speed
Time from a failed step to knowing whether it's configuration or a defect.
Change-board evidence
Whether the board approves transports from run records.
Where it doesn't fit. Robonito tests SAP through Fiori and web-based SAP UIs. It doesn't automate SAP GUI for Windows, and it doesn't analyze transports for impact, so pair it with your process map or an impact-analysis tool.
08Rolling it out: the first month
A realistic plan for a team starting from zero, with the baseline comparison built in.
- Week 1
Pick two processes
Process owners choose order-to-cash and procure-to-pay as the first processes to automate in Fiori.
- Week 2
Write them as tests
Key users describe each process step by step in plain language, with checks at each step.
- Week 3
Run around transports
Azure DevOps runs the suites in the quality system before and after each transport import.
- Week 4
Bring evidence to the board
The change board reviews run records for the week's transports, and the team decides which processes to add next.
09Frequently asked questions
Does Robonito support SAP Fiori?
Yes. Robonito tests SAP through Fiori apps and web-based SAP interfaces. It does not automate SAP GUI for Windows, so keep a GUI-capable tool for transactions that only exist there.
Can business users write SAP tests?
Yes. Process owners describe a process in plain language, step by step, and the agent turns it into a test they can read and review.
Does Robonito analyze transports for impact?
No. Robonito runs your process tests before and after transports but doesn't analyze transport contents. Pair it with your process map or an impact-analysis tool to decide what to run.
Can Robonito test Oracle, Workday or ServiceNow as well as SAP?
Yes. Robonito has solutions for Salesforce, SAP, Oracle, Workday and ServiceNow, so a mixed enterprise estate can be tested from one platform.