Case study · Adobe AEM customer journeys

Six months of journey testcoverage, built in 10 days.

Banks and enterprises run digital customer journeys on Adobe Experience Manager, onboarding, lending, and servicing flows with dozens of branching variants. Lab0's AI forward-deployed engineer turned months of manual journey QA into an automated, debuggable Playwright suite, discovery to review-ready specs, in days. The numbers below are from one engagement, not a brochure.

6 months → 10 days·4 automation suites·Backed by Y Combinator

Validating AEM customer journeys by hand doesn't scale.

Each journey spans multiple entry points, identity checks, OTP validation, KYC selection, document capture, profile detail, review screens, and submission checkpoints, and every one of those has variants. Manual regression is slow, repetitive, and quietly leaves gaps.

~6 mo
To author coverage manually
Building dependable regression coverage across every journey and variant by hand is a multi-month QA effort, and it goes stale the moment the flow changes.
Many
Variants per journey
New-to-bank vs. existing customer, Aadhaar vs. OVD KYC, branch-code routing, assisted vs. unassisted, the same journey multiplies into dozens of paths that each need validating.
Hidden
Dependent fields & validations
Conditional fields, validation messages, and modals only appear under specific states, exactly the cases manual scripts skip and production incidents come from.
Multi-step
Checkpoints to assert
OTP, KYC selection, document upload, preview, and final submission each carry their own state and error handling that must be asserted, not assumed.
Mocked
API & fixture states
Journeys depend on mocked API responses and fixtures; every state combination expands the matrix a manual tester has to keep in their head.
Repeated
Every release cycle
The same journeys get re-tested by hand on every release, effort that compounds while confidence stays flat.
01Coverage gaps surface as production incidents
02Manual regression can't keep pace with releases
03Locators drift and quietly break ad-hoc scripts
04No clear record of what's covered vs. skipped

How Lab0's AI FDE covers AEM journeys.

The same standardized workflow runs every time, turning real AEM journey screens and Journey Understanding Documents into stable page objects, comprehensive test cases, generated Playwright specs, and a debugging loop that pinpoints the true failure. It encodes best practices with every rollout instead of starting from scratch.

01 · Discovery

Extract stable page objects

The DOM Page Object Extractor inspects DOM captures, screenshots, JSON snapshots, and live journey pages to identify reliable locators, visible controls, hidden dependent fields, validation messages, modals, and navigation checkpoints, converting real AEM screens into resilient Playwright page objects.

$lab0 extract page-objects --from dom,screenshots,snapshots
02 · Solution design

Derive comprehensive test cases

The JUD Test Case Extractor reads Journey Understanding Documents and converts them into full coverage, positive and negative scenarios, validation rules, branching flows, API dependencies, KYC paths, upload and preview behavior, and final-state expectations, so the design reflects the journey, not a happy path.

$lab0 derive cases --from jud --cover positive,negative,branching
03 · Configuration

Generate journey specs to convention

The Journey Spec Generator turns extracted cases and page objects into Playwright .spec.ts files that follow the repo's own conventions, test IDs in titles, journey-specific config, reusable helpers, page-object methods, and safe handling of skipped or fixture-dependent tests.

$lab0 generate specs --convention repo --emit playwright
04 · Testing

Debug to the true failure point

The Playwright Failure Debugger finds where a run actually breaks, a document-upload test failing because PAN didn't fill on the identity step, for instance, then classifies it as environment, data/config, locator drift, missing waits, API/mock mismatch, product behavior, or browser fallout, and recommends the smallest safe fix plus a verification command.

$lab0 debug --classify --suggest-fix --verify

What the suite delivers.

A reusable, scalable automation layer for validating customer-journey behavior before production, review-ready for your team and built to extend journey by journey, getting faster with each one.

Page objects

Resilient locators

Stable Playwright page objects per journey, built to absorb DOM drift across variants instead of breaking on the next AEM authoring change.

Test specs

Convention-clean .spec.ts

Journey spec files that follow the repo's conventions, test IDs in titles, journey config, reusable helpers, and safe handling of skipped or fixture-dependent tests.

Evidence

Covered, skipped, blocked

A clear record of exactly what's covered, what's skipped, what's blocked, and what's pending fixture support, so release decisions are evidence-based.

Review-ready

Multiple journeys

End-to-end suites span multiple customer journeys, handed over for review and extension, the framework grows with each one rather than restarting.

Evidence, not guesswork.Every run pinpoints the real failure and surfaces gaps in test data and mocks, so the team knows precisely what's validated before a production rollout, and the suite gets sharper with each journey it covers.

Book a demo.

If validating your AEM customer journeys takes months, give us one of your hardest flows and we'll run the AI FDE end to end. The coverage report will speak for itself.