Selected work
Test automation framework built from scratch for a SaaS team
Engagement at a glance
- Automation Framework
- 2025
- Growing SaaS product team
What happened
Challenge
Fully manual regression testing took the team several days per release, so releases shipped late — or shipped untested. Automation attempts had stalled on flaky record-and-playback scripts: selectors broke on every refactor, failures were as likely to be the test as the product, and the team had learned to re-run a red build rather than investigate it. At that point the suite was costing time without buying confidence.
Approach
We built a Playwright + TypeScript framework from scratch: page-object architecture, isolated test data fixtures, parallel execution and CI gating on GitHub Actions, then automated the critical user journeys iteratively. Each test creates and tears down its own data, so tests do not depend on each other or on the state left by a previous run — which is what had made the earlier attempt unreliable. We started with the journeys that carried revenue and added coverage in reviewable increments rather than attempting the whole suite at once.
Outcome
Automated checks now run on every pull request, and the team can extend the suite themselves. Isolated fixtures and failure reports make the tested journeys repeatable and help the team investigate a failed run before deciding whether to merge.
Measurement context
The published evidence describes the framework and CI workflow. Comparable measurements of manual effort, automated runtime, coverage and maintenance time are not provided, so this case does not quantify time saved or an AI-related productivity improvement.
Why this stack
Playwright over the incumbent record-and-playback tool for two specific properties: auto-waiting, which removes the largest single source of flakiness, and a real programming model, which is what makes page objects and shared fixtures possible at all. TypeScript because the tests are code and deserve the same compile-time checks as the product. GitHub Actions because the team already lived there and adding a second CI system would have been a new thing to maintain.
What we would do differently
We automated a handful of journeys before the test data story was settled, and those early tests had to be rewritten once fixtures created and destroyed their own data. Isolated test data is not a refinement you add later; it is the thing that decides whether the suite can run in parallel. We would build the fixture layer first now, even though it delays the first green test by several days.
Stack
- Playwright
- TypeScript
- GitHub Actions
- Allure
Contact
Something similar in flight?
Describe where it currently stands and what worries you about it. You will get a considered reply from an engineer, not an autoresponder.