Change Impact Analysis in UiPath Test Cloud answers one question: which SAP transactions were touched by the transports of the last thirty days. It sorts the answer into three buckets. A transaction that was touched and has a test case assigned to it is Fit. Touched with nothing assigned is Gap. Everything else is Not impacted.
The Gap list is the starting point for this article. It holds the transactions a change touched that have no test case assigned in Test Manager. In an SAP S/4HANA conversion those transactions can reach beyond the planned test scope.
One caveat before anything gets built on it: Gap measures coverage, not quality. It is not a readiness metric - readiness also takes executed test results, defect status and a risk assessment. Gap is the first number in that conversation, not the last. Fit does not prove a test is any good either; it only proves one exists and is linked.
What follows is how we close that gap: how to decide what to test after a change, how to add performance testing before go-live, and where UiPath Test Cloud runs out of road. That last part comes from the vendor’s own documentation, including a dedicated known-limitations page that sales material rarely summarises.
A conversion does not break your test plan - it invalidates it
A regression suite that passed on SAP ECC for five years is, after the move to SAP S/4HANA, testing a world that no longer exists. Not because anyone broke it. Because the things it stood on have changed.
The data model. The Universal Journal, centred on table ACDOCA, consolidates financial data and replaces some of the separate line-item and totals tables that older reports and queries were built on. Not every earlier structure disappears - BSEG and BKPF remain. SAP ships compatibility views, so an old read may still return data - or may not, depending on the access method. A test that queried a totals table directly has to be checked on that specific point before you treat a passing result as reliable evidence.
Master data. Business Partner becomes the leading object for customer and supplier master data, and Customer/Vendor Integration is an entry condition for the conversion rather than a task for later. Scenarios built on the superseded customer and vendor maintenance transactions need reworking for Business Partner. If your ERP already ran on Business Partner, fewer adjustments will be needed - but CVI completeness still has to be verified before the conversion.
Field lengths. SAP S/4HANA allows material numbers of up to forty characters, though using longer ones takes a deliberate activation and an interface compatibility check. A test script with an eighteen-character format baked into it keeps passing and stays silent - until the day somebody enters a longer number.
The way people enter the system. Where the target process moves to SAP Fiori apps, automation built solely for SAP GUI has to be extended to the browser interface. SAP GUI automation cannot directly operate Fiori controls, even when the business process underneath is identical.
Custom code. Modification adjustment during the conversion, plus ABAP Test Cockpit findings for the target release, tell you what has to be rewritten. They do not tell you whether the rewrite works. That part stays with testing.
SAP Readiness Check for SAP S/4HANA will hand you simplification items - the changes calling for decisions and work before, during or after the conversion - and a custom code analysis. That is a good list of changes. The list of tests is a different artefact, and no tool ships it for you.
ISTQB is not decoration in a bid
Test methodology is often treated as a certificate to be quoted in a tender. In an SAP conversion, three principles from the ISTQB Foundation Level syllabus do the actual work, and they are worth naming.
Exhaustive testing is impossible. Every combination of processes, configuration variants and data in a mature SAP system cannot realistically be tested. Risk-based prioritisation is therefore not a shortcut for teams that ran out of time - it is ordinary practice, alongside the design techniques that cut the number of test cases while meeting a defined coverage criterion. “We will test everything” means, in practice, “we do not know what we are testing”.
Defects cluster. After a conversion they do not spread evenly. Our working hypothesis - to be checked against a given project’s data, not taken on faith - is that the clusters sit in custom code, in interfaces to surrounding systems, and in reports built on the old data model. The principle says clusters exist; where exactly, successive test cycles show.
Tests wear out. That is the name the v4.0 syllabus uses; earlier editions called it the pesticide paradox. The same test set, repeated often enough against unchanged software, stops finding new defects. After a conversion the software itself has changed, so an old regression suite does not so much lose value as measure something other than what its authors intended. It needs reviewing, not merely re-running.
On top of that sits craft that no tool replaces: test levels with clear ownership, entry and exit criteria written as numbers, a requirements traceability matrix, and a defect classification that keeps severity apart from priority. Without those, a management view in the tool reports activity rather than readiness.
It is also worth knowing that ISTQB maintains a separate track for this domain - Certified Tester Performance Testing. Performance testing has its own vocabulary, its own risks and its own way of setting objectives. It is not a harder version of functional testing.
Heatmap and Change Impact Analysis: deciding what to test
Here is where the tooling starts. UiPath Test Cloud answers “what should we test after this change” from two sources: real usage of the system, and the content of the transports.
The ABAP add-on. Both features need a component on the SAP side. Objects land in the /UIPATH/ namespace and delivery goes through transport requests - one for Heatmap, a separate one for Change Impact Analysis. This is not an installation via SAP Notes or SAINT. On the RFC path the communication user needs the S_RFCACL authorisation object; over a web service connection that requirement does not apply.
Heatmap. It shows what is used in production and how heavily, overlaid with test coverage status. The score is computed from five SAP attributes with configurable weights that must sum to one hundred: Users at a default weight of 40, Intensity at 30, and Execution, Time and Object at 10 each. Because you can re-weight them for a given client, the picture of “what matters” is a decision, not an oracle. Data is polled from SAP on a cycle no shorter than one hour.
Runtime labelling. When SAP monitoring is enabled in a Studio project, executed transactions receive automatic labels in the form TRAN:ME21N or PROG:PROGRAMNAME. That is how Heatmap knows what has been tested, without manual mapping.
Change Impact Analysis. The input is selected SAP transports from a window of the last thirty days - it does not automatically cover every change introduced by the conversion. The analysis maps impact onto transactions, onto technical interfaces - SAP BAPI, SAP RFC, SAP QUERY and SAP IDOC - and onto security transactions together with the affected users. The view has three tabs: UI, API and Security. For transactions in the Gap state, Autopilot for Testers can draft test cases, but the output needs human review. It is a draft, not a finished test.
Connection architecture. The vendor’s recommendation is simple, and worth carrying into a project unchanged: connect Heatmap to the production system and Change Impact Analysis to the quality system. Heatmap is there to tell you what is genuinely used. Change Impact Analysis is there to tell you what you are changing, before it reaches production.
How it is metered. Full Change Impact Analysis functionality depends on transport units. One unit is consumed per unique transport, and re-analysing the same transport is free. Without licences you are left with the overview only. This matters for planning, because a cutover produces transports in batches.
The practical effect in SAP projects looks like this: instead of a full regression you get the list of transactions touched by one specific change package, with the coverage gaps marked. The conversation with a process owner stops being a negotiation about time and becomes a decision about risk.
Performance testing: a green regression is not a ready system
A functional test answers whether a process behaves correctly. A performance test answers something else: how the system behaves under a defined load - say, three hundred users arriving at eight in the morning while period-end close runs in the background.
That second test is often skipped, because it needs its own plan, its own infrastructure and its own expertise. The blast radius of a failure depends on the defect rather than on its category - but some performance problems surface only under a particular load, data volume or level of concurrency. Without a test that reproduces those conditions, they show up after go-live, with the whole audience watching.
What the SAP layer contributes
Before the conversion. SQL Monitor and the SQL Performance Tuning Worklist show, on the old system, which pieces of custom code are genuinely expensive in production. This is a good use of the early-testing principle: find the expensive statement before the conversion, then measure it again on the target system. Some queries genuinely do speed up on the new data model - but which ones is not something to assume in advance.
During and after. The ST03N workload monitor and STAD single-record statistics give response times broken down by task type. The /SDF/MON report collects snapshots of work processes, memory and CPU for incident analysis. SAP Focused Run adds real user monitoring and synthetic user monitoring - a repeatable measurement of the same flow over time.
Keep in mind what this layer is: monitoring and application lifecycle management, not a load generator. It will tell you how the system behaves under load. It will not create three hundred users.
What UiPath Test Cloud contributes
Performance scenarios in UiPath Test Cloud take the functional automations you already maintain and run them in parallel as load. That is the heart of the proposition. If your purchasing-process regression is already automated, you do not write a load script from scratch. The same automation becomes a scenario, and you add virtual users, ramp-up time and thresholds on top. The condition is compatibility: supported activities, package versions, and data that allows concurrent execution.
Load is generated through the user interface or through API calls. The available run types are load, spike, stress and endurance. Results - response times, errors, throughput - appear in Test Manager alongside functional results, rather than in a separate tool behind a separate login. Diagnosing the underlying cause still takes application and infrastructure monitoring.
Licence units convert at a fixed ratio: one desktop virtual user equals ten browser virtual users equals one hundred API virtual users. A bundle covers 2,500 virtual user units and 250 runtimes. Units are reserved for the duration of a test and return to the pool when it ends. The units are not the whole bill, though: serverless execution also consumes Platform Units, and test authoring and runtime licences come on top. How many virtual users of a given type a bundle actually supports has to be worked out for the specific scenario before the number reaches a proposal.
The six additions from August 2026
The vendor packaged these as making performance testing easier to start and to scale. Four of them solve real project problems.
Workflow Analyzer as a pre-run gate scans the automation and catches what cannot run inside a performance test: computer vision, OCR, hardware events, local file access, desktop-only patterns, and version drift between Studio and packages. Previously each of those broke the run mid-flight.
Capacity Planner replaces static CPU and memory estimates with a short series of load probes on the real infrastructure, and derives a virtual user recommendation from them.
Elastic Robot Pools generate load from your own resources in Azure, AWS or Google Cloud instead of shared infrastructure. For a client with a data-residency requirement that is a strong argument, though not the whole answer - the regions and data flows of the remaining services still need checking.
Firewall-resilient metrics. With port 5671 blocked, metric delivery falls back to WebSocket over port 443 and, if needed, to an API-based path. This covers the metrics rather than every connection the test makes - but that one port was usually the reason a test sat in the network team’s queue.
The package also brought reports prepared separately for the programme manager, the developer, the infrastructure team and the testers, plus robot log review filtered by load group and severity.
Where this does not work
This section is here so that nobody has to discover it in week three of a project.
Change Impact Analysis needs a direct connection into the SAP system. The CSV file path feeds Heatmap only. If a client will not agree to that connection, impact analysis simply does not run.
The analysis takes system usage and transport content as its input. UiPath also collects dependencies observed at runtime, but deep static tracing - which ABAP object is used where, and what breaks when it changes - belongs to a different class of tool. SAP sells that one as SAP Change Impact Analysis by Tricentis, drawing on LiveCompare and the cloud-based SeaLights for ABAP; their analysis scope and deployment models are worth comparing for a specific landscape. On a large, heavily modified system the two approaches complement each other. The claim that one replaces the other will not survive a conversation with an architect.
Performance execution has hard boundaries. A serverless run in the cloud stops after sixty minutes, so an overnight endurance test needs robots on your own infrastructure or Elastic Robot Pools. Desktop scenarios - load driven through SAP GUI - do not run serverless at all. The configuration guide lists 500 virtual users per load group and 2,000 per scenario, while the limitations page allows up to 10,000 on your own infrastructure. Those figures describe different layers and do not add up to one number, so confirm the limit for your mode with the vendor before it goes into a test plan as a promise.
UI-driven load is expensive. One virtual user driving a screen consumes far more resources than one generated at protocol level. That is the price of realism and of reusing functional tests. For scenarios in the many thousands of sessions, price it honestly instead of assuming it scales linearly.
There is no historical comparison before the first run. The first completed, representative run is what can serve as a baseline. Trends and regressions come from comparing successive comparable runs, not from a single one.
Playwright in Test Manager has three limits and one trap. Since 4 September 2026 the platform runs existing Playwright cases in JavaScript and TypeScript without rewriting them in Studio - but under controlled availability, on the Chromium engine only, and serverless only. The trap is in reporting: a test that passes on retry is reported as passed. The earlier failed attempts stay visible in the Attempts tab, and the result attachment carries the flakiness flag. If you are accountable for test stability, you have to go after that deliberately.
The AI model in Autopilot for Testers has a deadline. GPT-4o support ends on 31 October 2026. The model has to be switched in the AI Trust Layer policy before that date, because connections pointing at a retired model stop working.
On market position, plainly. UiPath is one of the Leaders in the inaugural Gartner Magic Quadrant for AI-Augmented Software Testing Tools from October 2025. One of several, not the only one, and that is still the latest edition of the report.
You will not find figures such as “seventy percent faster test automation” in this article. They circulate in sales material and we have no primary source for them, so we do not repeat them.
How we run these projects at SNOK
We work to the testing principles and vocabulary set out in the ISTQB syllabi and to the SAP Activate phases, because those are the two frames a client and an auditor recognise without translation. ISTQB is not a project methodology - it is a shared language and a set of principles you build a plan on.
The engagement opens with a test strategy: levels, types, design techniques, entry and exit criteria per level, defect management and metrics. Then a test plan per level, a requirements traceability matrix, and test cases written before automation rather than after it. It closes with a completion report carrying a go or no-go recommendation, the residual risks, and an explicit statement of what we deliberately did not test.
Across SAP Activate the work falls out naturally. In Explore, Heatmap and Change Impact Analysis build the picture of usage and coverage gaps. In Realize, regression automation is built and system and acceptance testing are supported. Performance testing is scheduled in the strategy and run as soon as the environment is representative. In Deploy we run pre-go-live regression, the analysis of cutover transports, and confirm the agreed readiness criteria. In Run, change impact analysis keeps working as a standing radar in application management.
One more rule we have held to since late July 2026. Every project with an agentic component - and Autopilot for Testers is one - carries a separate set of test cases in the test plan checking the agent’s resistance to instruction hijacking. The basis is a published experiment by Paweł Cynkar against an agent under a hard ban on using general knowledge: of sixty-eight attack vectors, twenty classic ones bounced off the guardrails, while three techniques - cloze-style completion, injecting content into the knowledge base, and asking for the rules to be translated - reconstructed the system instruction in full. One conclusion follows: a prohibition in a prompt is not a security control. A test completion report without that section has nothing to say about the agent’s resilience. We developed this further in why an AI assistant’s refusal is not a security control and in the piece on the human oversight gate in UiPath Maestro.
Our team combines SAP and UiPath expertise, alongside SAP Basis and SAP security. In practice that means the conversation about S_RFCACL, about SAP GUI scripting, and about the effect of a load test on a production system happens inside one team rather than between two vendors through meeting minutes.
Three things worth doing this week
Check whether you know what is genuinely used in production. Not from process documentation - from data. Without Heatmap, ST03N and a transaction list for the last quarter are enough to start. Transactions with no recorded usage in the period you analysed are candidates for review with the process owner - bearing in mind the seasonal, mandatory and contingency processes that run rarely and still have to be tested.
Run SQL Monitor on the old system if the conversion is still ahead of you. It collects the real production cost of custom code. The longer it runs before the conversion, the better the picture you get.
Write your go-live exit criteria as numbers. Not “testing completed successfully”, but “all priority-one cases passed, pass rate at least ninety-five percent across the agreed scope, zero open critical defects, dialogue response time below the agreed threshold at target load”. The pass-rate threshold is a project agreement, not an ISTQB norm. A sentence written down in advance settles the argument that otherwise erupts on the Friday of the cutover weekend.
That leaves one question, worth asking yourself before the first meeting about testing: do you know which transactions in your system have no test case assigned to them? Neither answer is embarrassing, because that list rarely assembles itself - a tool has to go looking for it. It is, however, the first number from which a serious conversation about conversion readiness begins.
We wrote more about the underlying shift in SAP testing in SAP testing as a release-confidence problem. If you are planning an SAP S/4HANA conversion or the launch of a new module and want to talk through the test plan, get in touch.
Sources: UiPath Test Manager and Test Cloud documentation (Heatmap, Change Impact Analysis, RFC connection, performance scenarios, Playwright), Test Manager release notes for August and September 2026, SAP Help documentation for ST03N, STAD, /SDF/MON and SAP Focused Run, the ISTQB Foundation Level v4.0 syllabus and the Certified Tester Performance Testing track. As of 9 September 2026.