Insights
Test automation
Frameworks, tooling and the parts nobody writes about: what makes a suite flaky, why record-and-playback stalls, and what a team needs in place before automation returns more time than it consumes.
Where we stand
Automation is a maintenance commitment before it is a time saving, and teams that treat it as the second without budgeting for the first end up with a suite they distrust and re-run rather than investigate. A red build that nobody believes is worse than no build at all, because it teaches people to ignore the one signal you were paying for.
Flakiness is almost never mysterious. It is shared state between tests, timing assumptions dressed up as waits, or an environment that differs from run to run. Each has a known fix, and each fix is structural rather than clever, which is why the answer is usually to build the fixture layer before writing the second test rather than after the fiftieth.
We start automation at the level where a failure names one thing. A browser test that goes red tells you a page is broken; a service-level check tells you which component broke it. The browser tier should be the smallest part of a suite, covering the journeys that genuinely require a browser, with everything else answered faster and more precisely underneath.
The deciding constraint is usually not technical. It is whether the client team can read and extend the suite after handover, because a framework only one supplier understands has a half-life measured in months.
Articles on Test automation
- CI test gating: deciding what a red build is allowed to stopWiring 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.
- Diagnosing flaky tests: a procedure, not a retryA 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 data management: five strategies and what each one costsHow 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.
- Playwright vs Cypress: one architectural difference, and its consequencesThe two runners differ structurally in one way, and nearly every practical distinction falls out of it. What that means for redirects, parallelism, debugging, and who ends up maintaining the suite.
- When to automate a test, and when the answer is noNot a philosophy of automation but a decision taken one case at a time. Five signals, four possible verdicts, and why "keep it manual" is not the losing option.
- Manual testing vs test automation: which to invest in firstAutomation is not a more advanced form of manual testing. They answer different questions, and picking the wrong one first is an expensive way to learn that.
- Building a test automation framework from scratch: the first 90 daysWhat actually gets built, in what order, and why the teams that start by recording scripts end up rewriting everything.
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.