Software Engineering
Tests that catch regressions, not tests that inflate a coverage number
A test suite is worth having when it makes you willing to deploy on a Friday. Most are not, for one of two reasons: they test the code rather than the behaviour, so they break every time anything is refactored and pass while checkout is broken — or they are so flaky that everyone reruns them until they go green.
Indicative
From £4,500
Fixed price agreed in writing before any build starts.
Get a quote+44 7488 265083The problem this solves
Coverage percentage is the metric that causes this. Chasing 80% produces hundreds of tests on trivial functions and none on the four journeys that produce your revenue. Meanwhile a flaky suite is actively harmful: it trains a team to ignore red, which is worse than having no tests at all.
What you get
Test the journeys that earn money
Signup, login, search, add to basket, checkout, payment, admin fulfilment. Full end-to-end coverage of these first, before anything else gets a test.
The right test at the right level
Unit tests for logic, integration tests for the data layer, end-to-end only for real journeys. End-to-end tests are slow and brittle; using them for everything is why suites get abandoned.
Zero tolerance for flakiness
A flaky test is a defect and gets fixed or deleted, never retried into passing. Deterministic waits and seeded data instead of arbitrary sleeps.
Wired into CI as a gate
Running on every pull request and blocking merge on failure, with the run time kept short enough that nobody is tempted to skip it.
Accessibility and cross-browser checks
Automated axe checks on key pages, and real runs in Chrome, Safari and Firefox. Safari-only layout bugs are common and invisible if you only test in Chrome.
Failures you can diagnose
Screenshots, video and traces captured on failure, so a red build is a two-minute diagnosis rather than an afternoon of local reproduction.
How we work
Find the critical paths
Which journeys, if broken for an hour, would cost you money or customers. That list is the test plan.
Assess what exists
Current tests reviewed for what they actually assert. Some get kept, some get deleted — a test that cannot fail meaningfully is worse than none.
Build the harness
Test data seeding, fixtures, and an environment tests can run against repeatably.
Automate the critical paths
End-to-end coverage of the priority journeys first.
Gate the pipeline
Wired into CI with required checks, and the suite kept fast.
Hand over
Your developers writing tests in the same patterns, because a suite only one contractor maintains dies when they leave.
What you should expect
- Regressions on revenue-critical journeys caught before release
- A suite the team trusts, so red means stop
- Deploys that no longer need a manual click-through first
- Failures diagnosable from CI without local reproduction
Built with
- Playwright
- Cypress
- Vitest
- Jest
- PHPUnit
- Pest
- Testing Library
- axe-core
- GitHub Actions
- Lighthouse CI
- k6
Mainstream, well-supported technology — chosen so you can hire for it and so another team could take the project over.
QA & Software Testing — your questions
Including the ones about cost, which most agencies leave off the page.
Automating the critical journeys for a typical web application runs £4,500 to £12,000 depending on how many there are and how testable the application currently is. Where the app has no seams for testing, some refactoring comes first and we scope that separately rather than hiding it.
We do not target a percentage, because it is the wrong measure — 90% coverage with no checkout test is worse than 40% with one. The target is that every revenue-critical path is covered end to end and every bug fixed comes with a test that would have caught it.
Playwright for new work: real cross-browser support including Safari, better parallelism, and its trace viewer makes failures much faster to diagnose. Cypress is a fine tool and we maintain existing Cypress suites rather than insisting on a rewrite.
Yes. Sometimes the application needs small changes to be testable — stable selectors, a way to seed data, a hook to control time. Those changes are worth making regardless, because code that is hard to test is usually hard to change.
For exploratory testing before a significant release, yes — a human finds usability problems no assertion will. For regression testing, no: repeating the same checks manually every release is expensive, unreliable and exactly what automation is for.
Related services
Most projects touch more than one of these.
Custom Software
Bespoke systems that replace the spreadsheets, manual handoffs and off-the-shelf tools your business has outgrown.
Read moreDevOps & Cloud Engineering
Automated pipelines, infrastructure defined in code, and monitoring that tells you about a problem before a customer does.
Read moreAPI Development & Integration
APIs other developers can use without asking you questions, and integrations that degrade gracefully when the other end breaks.
Read moreWeb Development
Custom websites and web applications engineered for speed, search visibility and long-term maintainability.
Read moreMobile App Development
iOS and Android apps built for retention, not just launch — with store submission, analytics and post-release support included.
Read moreSecurity Audits & Hardening
A manual audit with working proof of concept for each finding, a prioritised fix plan, and a retest that confirms it.
Read moreTalk to someone who has built this before
A short call is usually enough to tell you whether this is the right service for your situation — including when it is not.