QA & test automation
Test suites that catch genuine regressions, run fast enough that nobody is tempted to skip them, and do not need constant repair. Plus honesty about the parts not worth testing.
The two failure modes of automated testing
The first is having none, so every release depends on someone remembering to check the right things. It works while the team is small and the person who remembers is still employed.
The second is worse in a specific way: a large suite that is slow and unreliable. Tests fail for reasons unrelated to the change, so people re-run them until they pass. At that point the suite is costing time and providing no information, and the team has learned to ignore a red build — which is the actual danger.
A good suite is smaller than most people expect. Heavy coverage of business logic where bugs are expensive, a thin layer of end-to-end tests over the handful of journeys that must never break, and nothing at all in places where the maintenance cost exceeds the risk.
What we do
Test strategy
Which layer each thing should be tested at, and what to deliberately leave untested. Written down, so the decision is reviewable rather than accidental.
Unit and integration tests
Dense coverage of business rules and data handling, where failures are cheap to find and expensive to miss.
End-to-end tests
A deliberately small set covering the journeys that must never break — checkout, login, payment — built to be stable rather than comprehensive.
Fixing flaky tests
Usually timing assumptions and shared state. We fix the causes rather than adding retries, because a retried test has stopped being evidence.
CI integration
Tests running on every pull request, parallelised to stay fast, with clear reporting on what failed and why.
Accessibility and performance checks
Automated WCAG and page-weight checks in the pipeline, catching regressions that manual review reliably misses.
Typical stack
Chosen per project, not by habit. If your team already runs something that works, we use it.
- End-to-end
- Playwright
- Cypress
- Detox for mobile
- Unit and integration
- Vitest
- Jest
- pytest
- Testcontainers
- API testing
- contract tests
- schema validation
- recorded fixtures
- Pipeline
- GitHub Actions
- parallel execution
- flake detection
- coverage reporting
How a QA engagement runs
We start from your actual defect history. The bugs that reached production tell you where the risk really is, which is usually not where a coverage percentage would point you.
- 01
Assess
Existing tests, defect history and release process reviewed. Where are failures actually coming from, and what would have caught them?
- 02
Stabilise
Flaky tests fixed or removed first. An unreliable suite must become trustworthy before it is worth extending.
- 03
Extend deliberately
Coverage added where the risk analysis says it pays, at the cheapest layer that can catch the problem.
- 04
Hand over
Your developers writing and maintaining tests as part of normal work, which is the only arrangement that survives us leaving.
Common questions
What test coverage percentage should we aim for?
Coverage percentage is a poor target — it is easy to reach a high number while testing nothing that matters. The better question is whether your last ten production bugs would have been caught, and that is what we measure against.
Our test suite is slow and unreliable. Is it worth saving?
Often yes, and the fix is usually removal rather than addition. Deleting the tests that provide no information and stabilising the ones that do typically produces a faster, smaller, more trustworthy suite within a few weeks.
Do you do manual testing too?
Exploratory testing before major releases, yes — automation cannot find problems nobody thought to check for. We do not provide large manual regression teams; that work should be automated.
Can you test an application you did not build?
Yes. We work from behaviour rather than internals, which is also the more robust way to write tests. Expect a short period of learning the domain first, and we price for it.
How does this fit with our developers?
The aim is that they own it. We set up the framework and patterns, write the initial suite, and work alongside your team until writing a test is a normal part of their work rather than a specialist activity.
Start with a scoping call.
Thirty minutes, no obligation. If we are not the right fit we will tell you on the call rather than after a proposal.
Related services
Custom software development
Web applications, internal tools, customer portals, APIs and mobile apps. Built by small senior teams in short…
Web application development
Portals, internal tools, dashboards and SaaS products. Built to be fast on a mediocre connection, operable by …
Cloud & DevOps
Migration without a big-bang cutover, infrastructure defined in code so environments are reproducible, and pip…