Home / Case study: UAT migration
Migrating 1,300 manual tests to automated acceptance testing
An ongoing migration from manual to automated acceptance testing on the reference-data management application of an agribusiness group. The client's name stays confidential.
1 · ContextBackground
The application manages an agribusiness group's reference data: about thirty interlinked entities, each with its own mandatory fields, input rules and dependencies. I work on it as a freelance QA Automation engineer.
2 · ProblemThe initial problem
- Acceptance testing relied on manual checks that had to be redone in full on every release.
- With 30 linked entities, a single inconsistent value can affect several screens.
- The business teams who sign off on UAT don't read test code.
3 · ScopeScope of the engagement
- The 1,300 manual data validity and consistency tests migrated to Playwright.
- Automated end-to-end user journeys.
- Per-entity UAT documentation.
- Flaky-test diagnosis and run tracking.
4 · TechnologiesTechnologies
- Playwright and TypeScript for all tests.
- Azure DevOps in the project environment.
- Playwright execution reports, processed by a tracking tool built for the engagement.
5 · ApproachApproach
- The existing manual UAT migrated to automated acceptance testing, entity by entity.
- Tests built on a shared foundation, so a new entity plugs in without starting over.
- End-to-end scenarios that go through the UI, then restore the data to its original state.
- One UAT document per entity, written from the test cases: objective, steps, expected result.
6 · ChallengesTechnical problems encountered
A click swallowed by a widget
Clicking a full table row sometimes landed on a widget that absorbed the event. The Edit button stayed disabled and the test failed for no visible reason.
A search that returned the wrong row
Global search worked by keyword: searching "Mantem 2" also matched "Mantem 1", and the test ended up checking the wrong record.
Standalone reports
Each run produced a separate JSON report, with no overview of how durations and failures evolved.
Failures that were hard to read
Real application bugs had to be told apart from fragile tests before fixing anything.
7 · SolutionsSolutions implemented
- Targeted click on the Code cell, then an explicit wait on the button's state before acting.
- Search by Code, a unique identifier, for both verification and data restoration.
- A tool that imports Playwright reports and tracks durations, passes and failures over the last 10 runs, with a shared history.
- AI-assisted failure diagnosis to isolate real bugs, followed by a root-cause fix.
8 · ResultsObserved results
- Automated acceptance testing with 1,300 Playwright/TypeScript tests, ready to run on every deployment.
- Stabilized tests: the targeted-click fix was reused across the other screens.
- No more false negatives caused by the search, and test data restored exactly.
- Run-duration drift is visible in the dashboard.
- One UAT document per entity that business users can run through.
9 · LessonsLessons learned
- Select by unique identifier rather than by label: less ambiguity, restorable data.
- Wait for an explicit UI state rather than a fixed delay.
- Separate real bugs from fragile tests before fixing.
- Write UAT in the business's language, aligned with what the tests check.
A reference-data system or an application to make reliable?
Describe your context. I'll reply by email within two business days.