Selected work · Case study

From days of manual regression to under an hour

Company

Orange Polska

My role

I introduced automated end-to-end testing, built the test architecture and trained two testers

When

Since 2022

Team

Me, one newly hired automation tester, and one manual tester who moved into automation

Stack

Cypress, TypeScript, Page Object Model

The situation

I joined Orange Polska to work on the Orange TV GO streaming platform. At the time, every end-to-end scenario was checked by hand by manual testers. A full regression campaign covered more than 100 scenarios and took at least one to three days.

How it started

I was taking a Cypress course at the time and wanted to put it into practice. Over lunch, I told my manager about end-to-end automation and how I would approach it. Then, instead of writing a proposal, I built it: a separate repository with the full setup, TypeScript and linting, and a first set of working tests. When my manager saw it working, he started looking for an automation tester to hire.

Options I considered

• Selenium: too complicated, with too much setup for the team we had.
• Playwright: promising, but not mature enough at the time.
• Cypress: modern, widely used, and a good fit for testing a web application. I chose it.
• A separate repository. The tests were written and owned by testers, not by the application's developers, so they lived in their own project.

Building the practice

• Training: everyone started with basic Cypress tutorials on their own. Then we wrote real tests together on my setup, and I reviewed every change during the first year. The team was one newly hired tester and one manual tester who moved into automation.
• Page Objects: interactions with each part of the application live in reusable page objects, so a change in the interface is fixed in one place.
• Shared helpers: common steps are written once and reused (DRY).
• Parallel runs: tests run side by side. That only works when each test is independent, so every test cleans up its own data through the API when it finishes.

1. Test scenarioDescribes one user journey, independent of every other test
2. Page ObjectsReusable interactions with each part of the application
3. Shared helpersCommon steps written once and reused
4. Parallel runScenarios run side by side; each cleans up its own data through the API

How it runs

• Orange TV GO: the suite runs in CI/CD on every feature merge request.
• The internal CMS: less than a year in, I moved to the internal CMS project, which got the same setup inside its frontend repository. That network is closed for security and its CI has no outside access, so the suite runs in parallel on a fast local machine instead.
• Environments: in both projects, the tests also run against the development, test and pre-production environments.

The outcome

Test data causes no trouble: the tests are isolated for parallel runs, and each one cleans up after itself.

What I'd do differently

Today I would choose Playwright with TypeScript. Its access to browser developer tools and its range of options make unusual scenarios easier to handle than in Cypress. Where the tests live should follow who writes them. I would keep them in the application's repository only if its developers write end-to-end tests themselves.

← Back to selected work