Home · Solutions · IT & services
Solution · IT & servicesThe portal and the app tested on every build, not on the last afternoon before release
Every release regression-tested, including the phone
Every build of the portal and the mobile app runs the regression suite unattended; failures reach the developer in Teams with the evidence, and release readiness is visible before the go decision.
Executive summary
Regression is a checklist two people click through on the last afternoon before a release.
We build the regression suite as a product asset rather than a release-week activity.
Regression stops being a slot in the calendar.
the customer portal and the iOS and Android builds; the policy, claims and payment services; the Azure DevOps backlog
Business problem
Release quality
A customer portal and a mobile app are where an insurer meets most of its customers between renewals. Policyholders log in to download a policy document, report a claim with photographs, pay an instalment, change a bank account, and buy or renew cover. Each journey crosses several back-end systems, and every fortnightly release can break any of them.
Regression testing is the promise that what worked last release still works. That promise is kept by two people and a checklist, in the only slot the calendar leaves. Under time pressure a checklist is not shortened by risk, it is shortened by order: the bottom steps go first, and the bottom is where the rarely walked journeys live, the tablet layout, the previous operating-system version, the customer with three policies.
The mobile app is harder than the web. A portal defect is fixed and deployed the same day; a defect in a released app version stays on the customer's phone until they update, and those who update least are usually on the least tested devices.
This is not felt only in IT. The contact centre absorbs the calls, the claims team receives half-finished notifications, and the product owner answers whether a release is safe with a feeling rather than a number.
How it works today
Whatever the delivery method on the wall, the regression itself usually looks like this.
- SystemThe sprint build is deployed to the test environment on Wednesday evening
- PersonTwo testers open the regression checklist in SharePoint and divide 180 steps between them
- WaitingTest data is built by hand first: a policy with an open claim, an unpaid instalment, a customer with three vehicles
- PersonWeb journeys are clicked through in one browser; the app is checked on whichever phone the tester carries
- Risk of errorWhen the afternoon runs out the remaining steps are dropped, and which ones is recorded nowhere
- PersonFailures are described in the release channel in Teams and, if reproducible, written up in Azure DevOps
- Risk of errorThe release ships on a verbal summary, and the first report of what broke comes from the contact centre or a store review
Why the current process costs more than it appears
The bill that never reaches the budget.
- Testing the same journeys by hand every fortnight buys nothing that lasts. Twenty-six afternoons a year produce twenty-six verbal assurances and no asset anyone can rerun tomorrow.
- Coverage falls exactly when it should rise. A release carrying many changes leaves less time to test, so the biggest changes get the thinnest check, and a team that cannot test cheaply answers with even larger releases.
- Defects found by customers cost several times more than defects found on a build. A portal fix is a hotfix and an apology; a mobile fix adds a store submission and the customers who never update.
- Accessibility and load are not on the checklist at all, because neither can be clicked through in an afternoon, so both end up in an external audit once a year, if at all.
Cost of inaction
Nothing in the release calendar forces this to change, which is why it has not. The afternoon returns every fortnight, the checklist is trimmed from the bottom, and the trimming stays invisible until a customer finds what was trimmed. The €8,000 per escaped defect is our own blend of the hotfix, the contact-centre contacts, the transactions re-entered by hand and the store submission a mobile fix needs; nine across twenty-six releases is not pessimistic.
What compounds is slower and less visible. A team that cannot test cheaply releases less often, which makes each release larger and harder to test. The accessibility pass keeps not happening, and the two people who can still say what the checklist really covers become the two the product cannot lose.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A European insurer, roughly 1,400 employees, about 600,000 retail policyholders in three markets; a customer portal and native iOS and Android apps, two product squads, a shared quality team of two, Azure DevOps, Microsoft 365 E3.
26 releases a year across the portal and both app builds; a checklist of about 180 manual steps covering twelve customer journeys; roughly three person-days of regression per release.
Two people walk the checklist on the afternoon before deployment, on one browser and one phone, with test data created by hand. Findings go into the release channel in Teams; the reproducible ones become Azure DevOps work items.
One afternoon is a fixed budget and the checklist is not. Steps are dropped in list order rather than by risk, mobile coverage is one device, and accessibility and load sit outside the exercise.
Test cases in UiPath Test Manager cover the twelve journeys on web, mobile and API level, drafted and maintained with Autopilot for Testers from the requirements already in Azure DevOps. Every build starts the suite through an Orchestrator API trigger, failures reach the responsible developer in Microsoft Teams with the evidence, and results synchronise back into Azure DevOps.
In the modelled case the regression that consumed an afternoon runs unattended on every build, the twelve journeys are covered across several device and browser combinations rather than one, and release readiness becomes a number. Illustrative, not a client result.
Proposed solution
We build the regression suite as a product asset rather than a release-week activity. Each of the twelve journeys becomes a requirement and a set of test cases in UiPath Test Manager, the part of UiPath Test Cloud that holds cases and execution evidence. Autopilot for Testers drafts them from the user stories already in Azure DevOps, generates the automation behind them and produces the synthetic test data each one needs.
Execution covers both channels and the layer underneath: web journeys against the browsers and screen sizes your customers use, mobile journeys against the app builds your pipeline produces, on the device and operating-system combinations your analytics say matter. Test Cloud supports web, mobile and API testing in one place, so one test set can drive a screen, call the service behind it and assert on both. Nothing waits for a person: after each successful build the pipeline calls an Orchestrator API trigger and the suite runs unattended. A failure becomes a work item linked to its test case, carrying the screenshot, the recording and the failing assertion, and reaches the developer who owns that area as an actionable notification in Microsoft Teams. Clients on Jira are synchronised there instead.
Above it sits a release readiness view: coverage per journey, pass and fail counts and the trend across builds, set beside open defects by severity in Power BI. Where the client needs them, the same suite carries accessibility checks against WCAG criteria and performance runs covering load, spike, stress and endurance. This is a different job from nightly SAP regression, which protects one back-end system against the transports deployed into it, and different again from migration assurance, where a one-time data move is proven record by record before a cutover.
UiPath Test Cloud with Test Manager (test cases, evidence, Azure DevOps and Jira synchronisation, WCAG and performance testing); Autopilot for Testers (test generation, synthetic test data, self-healing); UiPath Orchestrator API triggers and audit; UiPath Action Center actionable notifications in Microsoft Teams
The journey-to-test-case map and its risk ranking, the object libraries, the test data sets and their clean-up, the pipeline integration, the defect routing rules, the readiness report and the runbook
The pipeline step that starts the suite and waits for its verdict; the link to your device estate, a device cloud or an in-house lab; calls to the policy, claims and payment services that prepare and clean up test data
How the automated process works
- AutomationA successful build in Azure DevOps calls an Orchestrator API trigger and starts the test set for the areas the change touches
- AutomationTest data is provisioned: policies, open claims, unpaid instalments and consents are created through the services, then removed
- SystemRobots run the web journeys across the browsers and screen sizes in scope, and the mobile journeys against the new app builds on the device estate
- AutomationAPI checks run in parallel against the policy, claims and payment services; accessibility and performance suites run on their agreed schedule
- SystemEvery result lands in Test Manager with its evidence, and failures create or update Azure DevOps work items linked to the test case and the build
- PersonThe developer who owns the area receives the failure in Microsoft Teams and triages it as a defect, a test fix or an intended change
- AutomationThe readiness view updates: coverage per journey, pass rate, open defects by severity, trend across recent builds
Human-in-the-loop model
Automation handles
- Running the journey suite on web, mobile and API level after every build, unprompted
- Provisioning and removing the test data each case needs
- Collecting the evidence for every result and creating the linked Azure DevOps work item
- Maintaining element descriptors as interfaces change, and reporting which tests it repaired
People decide
- Which journeys belong in the suite and what risk each carries
- Whether a failure is a defect, an intended change or a test that needs updating
- The release gate: what may still be open when a build goes to production
- The accessibility and performance thresholds the portal must meet
Before and after
Systems and integrations
We do not add technology to make an architecture look serious. Every element below has a specific job in this process.
Inputs
- requirements and user stories in Azure DevOps
- build artefacts from the pipeline
- the twelve journeys and their risk ranking
- device and browser usage from your analytics
Automation layer
- UiPath Test Cloud with Test Manager
- Autopilot for Testers
- UiPath Orchestrator
- UiPath Robots
- UiPath Action Center
Target systems
- the customer portal and the iOS and Android builds
- the policy, claims and payment services
- the Azure DevOps backlog
- the Power BI readiness report
Human touchpoints: failure triage in Microsoft Teams; the readiness report; test case review in Test Manager
Technologies used
requirements, test cases, evidence, synchronisation with Azure DevOps or Jira
Adrafts tests from requirements, generates automation and synthetic test data, self-heals tests
Arun the suite unattended on API triggers from the pipeline, with retries and audit
Aroutes each failure to the developer who owns the area, evidence attached
Abuild pipelines that start the suite; the backlog where defects live
Atechnical credentials; hosts the test environments and robot machines
Athe release readiness report read before the go decision
Athe device and operating-system combinations mobile journeys run against
CIllustrative economic model
What it is worth, with the arithmetic shown.
A person-day here is 480 minutes, and 6.5 of them a month is the 26-release calendar spread evenly across the year; both are stated assumptions, not measurements at a client. €42 is a fully loaded hourly cost for a quality specialist in Central Europe. The model prices the manual regression only, not the defects that reach customers, which sit in the next section. It shows capacity released; how it is used is your decision.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- Regression stops being a slot in the calendar. Every build is tested, the release date no longer decides how much testing happens, and releases can be smaller and more frequent.
- Coverage becomes a fact rather than an intention: twelve journeys, on the browsers and devices your customers use, on every build, recorded per run.
- Defects reach a developer within minutes of the build that caused them, while the fix is still cheap.
- The mobile app stops being the channel nobody had time for, and accessibility and load become continuous checks rather than an annual audit.
The management view
- Release readiness becomes a number the product owner can show: coverage per journey, pass rate and open defects by severity, per build.
- The go decision leaves the realm of confidence. What was tested, what failed and what was accepted is recorded against every release.
- Delivery capacity grows without hiring, and what the team knows about quality stops being oral tradition and becomes test cases anyone can read.
Board-level KPIs
Security and governance
Trust in automation is built on the audit trail, not on a promise.
- Tests run against environments populated with synthetic customers, and the suite masks any field in a screenshot or recording that could carry personal data. Production policyholder data is not copied into a test run, which is the only version that survives a data-protection review.
- Each robot signs in with its own technical account. The secrets never leave Azure Key Vault, Orchestrator only references them, and the accounts carry rights in the test tenants and nowhere else.
- Requirements, results and evidence stay in your Azure DevOps project and the UiPath Automation Cloud EU region, where the execution history still answers months later who changed a test case and who accepted a failure.
Why now
Accessibility has stopped being optional for services sold online. The European Accessibility Act, Directive (EU) 2019/882, applies from 28 June 2025 and covers e‑commerce services, meaning services provided at a distance by electronic means with a view to concluding a consumer contract, which is what a portal selling and renewing policies does. Whether a given journey is in scope is a question for your legal function; either way, an annual audit is not a check on every build.
The modelled €26,208 a year of regression effort is the smaller half of the arithmetic. The defects one afternoon cannot catch are the larger half, and both are paid every year the checklist survives.
Authoring was never why automated suites decayed; maintenance was. Autopilot for Testers drafts cases from requirements, generates the automation and synthetic data behind them, and repairs tests when interfaces change, moving the effort to deciding what to test.
Relevant executive roles
Release quality becomes a measured property of the pipeline instead of an argument on the afternoon before deployment
The channels customers use are tested before they use them, so the contact centre stops discovering releases
The product releases more often, because proving a release safe no longer scales with the number of journeys
The released capacity is small and countable; the cost of defects reaching customers is larger and lands in service volumes, not the IT budget
Common questions and objections
The platform is shared and almost nothing else is. Nightly SAP regression protects one back-end system against the transports you deploy into it; this suite protects the two channels your customers touch, against browsers and phones that change on their own schedule. Most companies run both, often with the same team.
That is why maintenance, not authoring, is where suites die. The automation is built on shared element libraries rather than coordinates, Autopilot for Testers repairs what it can and reports what it repaired, and UiPath Healing Agent covers test automation as well as production runs.
Fast change is the argument for it. The journeys that matter most, logging in, reporting a claim, paying an instalment, change least and hurt most when they break. Start with those on two or three device combinations, then widen as the suite earns trust.
When this is not the right solution
- A product that releases twice a year and changes little in between, where a checklist is genuinely cheaper than a suite somebody has to maintain
- An application still being rebuilt, where screens and identifiers change every sprint for reasons that are not defects
- No test environment and no way to create test data, so every run would depend on production records
A question for the next management meeting
Before the next release goes live, what evidence will this company have that the portal and the mobile app still work, and who will have produced it?
Implementation approach
What we deliver, and what we need from you to start.
We deliver
- A journey and risk workshop: which journeys the suite must cover, what each is worth, what broken means
- Requirements and test cases in Test Manager, drafted with Autopilot for Testers from the stories you already write, plus the web and mobile automation and object libraries behind them
- Test data sets that create and clean up their own policies, claims and payments, so no run depends on a hand-built record
- Pipeline integration in Azure DevOps, defect routing into Microsoft Teams, and the ownership rules behind it
- The readiness report in Power BI, the accessibility and performance suites where in scope, and a maintenance runbook
We need from you
- A test environment that resembles production, app builds the pipeline can hand over, and your device and browser analytics
- Access to the services used to prepare test data, scoped to test data only
- A named product owner who can decide what the release gate requires
Stages
Discovery
Journeys, risk ranking, the current checklist, environments, device and browser mix
Design
Coverage matrix, test data strategy, gate criteria, defect ownership and routing
Build
Test cases and automation for web, mobile and API, pipeline integration, Teams routing
Stabilisation
The suite runs alongside the manual checklist until the two agree, then the checklist retires
Operation
Maintenance rhythm, flakiness management, accessibility and performance suites, quarterly coverage review
Departmental. Effort is driven by the number of journeys, how testable the application is (stable element identifiers, a service behind each screen), and how many device and browser combinations the matrix carries.
The regression you cut on Thursday afternoon is what your customers find on Friday.
Send us your current regression checklist and the release history of the last quarter. We come back with a journey and risk map, a proposed coverage matrix and a written assessment of what to automate first.
Automate your two riskiest journeysThe neighbouring process usually has the same problem
A spreadsheet sample of a few hundred records is what currently stands between your migration and go-live.
View solution IT & servicesAccess requests and quarterly access reviewsManagers sign off on entitlements they cannot read, and nobody withdraws what nobody uses.
View solution Customer serviceService levels reported before the customer disputes themMonthly SLA reports are rebuilt in Excel from ticket exports, and the customer finds the service credits first.
View solution IT & servicesEvery laptop accounted for, from order to wipe certificateHardware ordered by email, handed over without a record, and written off when the auditor asks.
View solution Case studySAP regression every nightInstead of three people clicking for two days — UiPath test agents walk the critical SAP paths every night.
View case study Case studyRobots that heal themselvesAn SAP screen changes and half your robot portfolio stalls? Healing Agent detects the interface change and repairs selectors on the fly, and our AMS team guards the whole.
View case studyIndustries we deliver this in most oftenRetail & e‑commerceServices & ITFinance & insurance