Your vendor picks the release date.
You still have to prove nothing broke.

Questions your security, QA and validation reviewers will ask

Can Lastest run entirely inside our own network?

Yes — that is the default deployment. Lastest is self-hosted: you run the containers on your own infrastructure, inside your perimeter, and point them at your sandbox, preview or prerelease environment. There is no callback to our infrastructure at run time, so it works on an isolated network segment and on hosts with no outbound internet access. Nothing about a production ERP or CRM screen has to leave your firewall for the regression run to happen.

Where do the screenshots and test data live?

On storage you control. Baselines, run screenshots, diff images and logs are written to the volume or object store you configure in your own environment. Because production ERP and CRM screens routinely contain customer, patient, employee and financial data, this matters for data residency, GDPR and GxP scope: the evidence never enters a vendor cloud unless you deliberately put it there. If your security review needs it, the runner can be operated with egress blocked entirely.

What happens to our regression suite if we stop paying?

You keep it. Your tests are plain Playwright code committed to your own git repository, and your baselines and screenshots are files in your own storage. There is no proprietary model repository to be locked out of and no export process to negotiate. If you leave, the suite still runs — it is Playwright, so any team with Node.js can execute it. That is the opposite of the usual arrangement in this category, where the tests live in the vendor format and leaving means starting the suite again from zero.

Does AI run when the tests replay?

No. AI is used at authoring time only — when you record a business process or repair a step, a model watches the interaction and writes the Playwright code and selector strategy. After that the model is out of the picture. Replay executes the committed code with no inference in the execution path, so the same run against the same build produces the same result and the same evidence. This is deliberate: an auditor, a Basis lead and a validation lead all need a run to be reproducible, and a model deciding at run time what to click is not reproducible.

How is this different from change-impact analysis tools?

It is complementary, not competing. Change-impact tools such as Tricentis LiveCompare and Panaya analyse metadata, code and usage to tell you which objects a release touches, so you can scope your regression. Lastest does not do that analysis and does not claim to. Lastest is what runs after the scope is set: it executes the business processes in a real browser and compares the rendered screens, so you can show what actually changed on screen rather than only which objects were flagged. Teams that own an impact-analysis tool typically use it to choose the scope and use Lastest to prove the outcome.

Do we need a git repository, and do our testers need to write code?

A git repository is strongly recommended because it is what makes the suite yours and gives you review history on every test change, but the runner can also read tests from a mounted directory if your organisation has no repo for QA assets. Test authors do not write code: a functional consultant or key user records the process by clicking through it, and the Playwright file is generated. The code is there so that engineers can read it, review it in a merge request and edit it when a process changes.

Why compare screens instead of asserting on fields and APIs?

Because a large share of release breakage is not an error. A tab gets renamed, a field moves to another card, a layout collapses on a Fiori tile, a button stops rendering for one role — assertion-based and API-level tests pass through all of that untouched, and the first person to notice is a user in production. Lastest compares the actual screen three ways: pixel comparison, structural (SSIM) comparison for layout shifts, and perceptual comparison for changes a human eye would register. Text-region-aware diffing keeps dynamic data like document numbers and timestamps from firing false positives.

What is a release-readiness review?

A 30-minute working session, not a product pitch. We map your next vendor-set release date — the support pack, the release weekend, the service update, the Release Preview window, the general release — to a concrete regression scope: which business processes have to be proven, which screens carry the evidence, and what the run looks like on your infrastructure in the window you actually have. You leave with the scope written down whether or not you go further with us.