For SAP QA managers, test managers and release managers
S/4HANA regression testing,
without running the entire universe every time.
ECC mainstream maintenance ends 31 December 2027. Lastest records your business processes once, then replays them deterministically after every FPS, support pack and conversion milestone — with screen-level diffs of GUI and Fiori.
The scoping problem
The test cycle ends when you run out of hours, not when you run out of risk.
On-prem and private cloud S/4HANA means a regression event at least every six months from feature pack and support pack stacks, plus an upgrade every one to two years — and, for most landscapes right now, a system conversion project on top. Two ways to handle the scope question.
Rebuild the scope by hand, every cycle.
A spreadsheet of test scripts, a distribution list of key users, and a round of chasing. SMEs are asked to do UAT on top of their day job, so the happy flow gets tested and the cancellation, the return, the reversal do not. Evidence is whatever screenshots someone remembered to paste into a document.
- Scope shrinks under time pressure, not under a risk decision
- Screen-level breakage is invisible — a moved field or a renamed tile passes every functional check
- Test evidence is manual — exports, PDFs, screenshot folders
- Nothing carries over, so the next support pack starts from zero
Record once. Replay after every transport, FPS and conversion milestone.
Walk a key user through the process once in the browser. Lastest writes the Playwright test into your repository and captures a baseline of every screen along the way. From then on the pack is an asset: replay it in your sandbox with production-like data, and read the diffs instead of rebuilding the scope.
- Scope compounds — each cycle adds tests instead of repeating work
- Screen-level diffs — visual, structural and perceptual, per step
- Evidence is generated, timestamped, and exportable for sign-off
- Runs unattended, so a full pack fits in one overnight window
- Nothing leaves your network — self-hosted next to the system under test
Impact analysis tells you what to test. Lastest tells you what actually changed on screen.
What Lastest drives, plainly stated
How it works in an SAP landscape
SAP picks the date. You still have to prove nothing broke.
Four things that decide whether a regression pack survives contact with an SAP landscape: where it runs, who owns it, what it compares, and whether the same run gives the same answer twice.
01 · Record
A key user clicks through the process. That is the test script.
Open the recorder against your sandbox or QA client, run the business process the way it is actually run — create the order, release the delivery, cancel the invoice — and stop. Lastest emits plain Playwright TypeScript into your git repository, with a layered selector fallback so a Fiori control that shifts in the next release does not take the whole test with it.
- No source access to SAP required — it exercises the running system
- Tests are reviewable in a merge request, like any other code you own
- Keep them if you ever stop using Lastest — no proprietary repository
02 · Diff
The tile got renamed. The field moved. Nothing threw an error.
A support pack does not usually break a system loudly. It renames a tile, reorders a column, changes a label, moves a field below the fold. Assertion-based tests pass right through it. Lastest compares each captured screen against its baseline with three diff engines — pixel, structural and perceptual — so a change a person would notice is a change the run reports.
- Per-step before and after, not a single end-of-test screenshot
- Text-region-aware comparison keeps dynamic document numbers from firing false diffs
- Approve an intended change once and it becomes the new baseline
03 · Replay
AI records the test once. Replay is deterministic.
Every tool in this category now puts a model in the execution path — agentic runtimes, AI locators, self-healing at run time. That is precisely what a Basis lead and an auditor cannot sign off on. Lastest keeps the model at authoring time. The run itself is ordinary Playwright: no inference, no variance, the same evidence every time.
- Reproducible runs you can defend in a go/no-go meeting
- Schedule the full pack after the transport lands, read results in the morning
- Wire it into your pipeline or run it standalone in a quarantined client
04 · Evidence
Test evidence that is generated, not assembled.
Every step produces a timestamped screenshot and a scored comparison against its baseline. That is the artifact your process owners sign against and your audit trail keeps — and it replaces the round of manual exports, PDF comparisons and screenshot folders that most teams still do by hand before a go-live.
- Exportable run artifacts, stored wherever you store them today
- Before and after per screen, so a defect ticket writes itself
- Same pack across sandbox, QA and pre-production for a like-for-like comparison
Where a replayable pack earns its keep
Common questions from SAP teams
- Which SAP screens can Lastest actually test?
- Anything your users reach in a browser. That covers Fiori apps and tiles, Fiori launchpad, Web Dynpro ABAP, SAP GUI for HTML (Webgui), and SAP Build Work Zone. Lastest drives a real browser with Playwright, so if the screen renders in Chrome, it can be recorded, replayed and diffed. It does not drive the SAP GUI for Windows thick client, and it does not automate SAP GUI published through Citrix. If a business process runs partly in the thick client, that part stays with your existing tool or with a key user, and Lastest covers the browser-rendered steps around it.
- How does this help before the 31 December 2027 date?
- Mainstream maintenance for SAP Business Suite 7 ends 31 December 2027, with extended maintenance available at a premium through 31 December 2030. Most landscapes are therefore running an ECC-to-S/4HANA system conversion project alongside normal support pack maintenance. Baseline the ECC screens your business actually uses today, then replay the same processes on the converted system and read the diffs screen by screen. The baseline is the argument you make to your process owners, and it costs nothing to capture early.
- Is this a change impact analysis tool?
- No, and we would not pretend otherwise. Tricentis LiveCompare and Panaya build metadata and ABAP graphs to predict which objects a transport or support pack touches. They tell you what to test. Lastest tells you what actually changed on screen once you have run it. The two are complementary: feed the scope from your impact analysis into a Lastest suite, and it comes back with visual, structural and perceptual diffs plus timestamped screenshots per step.
- Does anything leave our landscape?
- No. Lastest is self-hosted. You run it on your own infrastructure, inside your own network, next to the systems it tests. Production data on a Fiori screen never leaves your perimeter, which is usually the first question your security reviewer and your Basis lead ask.
- Where do the tests live?
- In your git repository, as plain Playwright TypeScript. You can read them, review them in a merge request, refactor them, and keep them if you stop using Lastest. There is no proprietary model repository holding your regression suite hostage, which is the usual complaint from teams that have tried to migrate off an incumbent enterprise tool.
- Where does AI fit, and is it in the execution path?
- AI is used at authoring time only. You click through the business process once, and Lastest writes the Playwright code and captures the baseline. Replay is deterministic: no model inference happens during a run, so the same suite against the same system produces the same evidence every time. That is deliberate, because a non-deterministic runner is not something a QA manager can hand to an auditor or defend in a go/no-go meeting.
- How do we scope a regression pack without running everything?
- Start from the processes that carry money and reputation: order to cash, procure to pay, period-end close, and the WRICEF objects and custom T-codes your team knows are fragile. Record those once. Because replay is cheap and runs unattended, the practical scoping question shifts from what can we afford to test to what did we bother to record. Most teams grow the pack one test cycle at a time, adding whatever broke last round.
- What does a test cycle produce for sign-off?
- Per step: a timestamped screenshot, the before and after baseline, and a diff scored by three engines (pixel, structural, perceptual). Per run: the full set as exportable artifacts you own. That is the thing teams currently assemble by hand, exporting reports to PDF and eyeballing them, and it is what a process owner signs against rather than a green checkmark.
Map your next
forced release date
to a regression scope.
Thirty minutes. Bring your next FPS, support pack or conversion milestone and the processes you cannot afford to have break. We come back with a scoped regression pack and what the evidence would look like. Runs on your infrastructure — production screens never leave your network.
Book a release-readiness review →# replay the pack after the support pack lands
$ lastest run --suite order-to-cash --env qas
✓ VA01 create order — 14 screens, no diff
✓ VL01N delivery — 9 screens, no diff
! Fiori: Manage Billing Documents — 1 screen changed
evidence: 214 screenshots, timestamped, exported