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
Regression feedback went from days of manual effort to minutes of automated checks on every pull request — and the team now extends the suite themselves. A failure points at one cause rather than requiring triage to decide whether the test or the product is broken, which is what made the team trust it enough to gate merges on it.
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.