03 /Test Automation
Playwright Test Automation
End-to-end coverage of your critical journeys written in Playwright and TypeScript: stable locators, isolated state, parallel workers and a trace attached to every failure. The measure of a browser suite is not how many tests it holds but whether a red run makes anybody look, and that is a design property rather than a tooling one.
What you get
Automated critical journeys
The flows where a failure costs money, written as tests that create their own data and clear it away afterwards. A test depending on a record somebody made by hand in staging is a scheduled outage.
A locator strategy your application supports
Tests address elements by role, by label and by test id rather than by a path through the DOM. That usually means adding a few attributes to your components, and it is the single change that most reduces breakage during a refactor.
Authentication solved once
Sign-in happens once per role and the resulting session state is reused, so a large suite does not spend most of its runtime at a login form. It also stops the login page becoming the reason everything is red.
Traces, video and screenshots on failure
Every failed run leaves an artefact that can be replayed step by step. Debugging a browser failure from a stack trace alone is how a team learns to distrust its own suite.
Parallel execution tuned to your runner
Sharding and worker counts set against the machine that will actually execute them, with a target wall-clock time agreed before the suite grows. A suite that outlasts the patience of a pull request gets skipped.
How it runs
- 01
Pick the first handful
We agree a small set of journeys to automate first, chosen by consequence rather than by an attempt at coverage. A few reliable tests gating a merge change how a team behaves; a large suite nobody believes does not.
You provide: A view on which journeys hurt most, and an environment we can reset
- 02
Build the vertical slice
One journey goes all the way through: fixtures, data setup, locators, per-environment configuration and a run inside your pipeline. Everything after it repeats a shape that has already been proven under real conditions.
We produce: A first test running in CI · Project structure and fixtures
- 03
Extend and stabilise
The remaining journeys are added, and each one is run repeatedly before it is accepted into the suite. A test that passes most of the time is not finished, and admitting one sets the standard for everything after it.
We produce: The agreed journey suite · A repeat-run stability record
- 04
Hand over the habit
Your engineers write tests in the suite while we are still there to review them, against conventions that are written down rather than absorbed. The point where they add one without asking is the point the work is finished.
We produce: Conventions documentation · Reviewed contributions from your team
Where this stops
- Not permission to convert every manual case into a script. Automating a check that runs twice a year costs more than running it twice a year.
- Not visual regression by default. Pixel comparison is available, and it is a decision carrying a maintenance bill rather than a box we tick on the way past.
- Not load testing wearing a browser. Driving many headless sessions measures your CI machine far more accurately than it measures your service.
- Not a rewrite of your application to make it testable. We will ask for test attributes and a resettable environment; changing the architecture behind them stays your team’s call.
Related reading
- Test automation
CI test gating: deciding what a red build is allowed to stop
Wiring a suite into a pipeline takes a day. Deciding what it may block is the real project, and it is a social agreement with a configuration file attached.
- Test automation
Diagnosing flaky tests: a procedure, not a retry
A retry policy converts an unreliable suite into a slow one that sounds confident. Four families of flake, the tell that identifies each, and the order to work through them.
- Test automation
Test data management: five strategies and what each one costs
How a test obtains the state it needs decides whether a suite survives parallel execution. Five approaches, the failure mode of each, and the problems nobody puts in the estimate.
FAQ
Playwright Test Automation questions we hear often
Why Playwright rather than Cypress or Selenium?
Auto-waiting, real cross-browser engines, first-class parallelism, and tracing that makes a failure explicable without a rerun. We have built and maintained suites in the others and would happily use them where a team already has one working. The runner is rarely why a suite collapses; shared data and DOM-shaped locators are, and swapping tools cures neither.
How many browser tests should we end up with?
A number decided by run time and by trust rather than by ambition. If your pipeline can wait a few minutes, that budget sets the size of the browser tier, and anything else worth checking belongs at the service layer where it costs a fraction of a second. Most products are well served by a modest set of browser journeys over a much larger suite beneath them.
Our login uses two-factor authentication. Can you still automate it?
Usually, though it needs a decision from you rather than a trick from us. The workable routes are a test-only bypass on non-production environments, a seeded shared secret the tests can derive a code from, or accounts exempted by configuration. What does not work is automating a code sent to a real handset, and anyone claiming otherwise is describing something fragile.
What happens when a test starts failing intermittently?
It gets a quarantine and a deadline, both agreed before the first flake ever appears. A test that cannot be made deterministic inside that window is deleted rather than retried into silence, because a retry hiding a real race condition is worse than having no test at all. A smaller suite you believe beats a bigger one you mute.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.