Software Testing and QA for UK Product Teams

It depends on the size of the product and what you need. A one-off test sweep or accessibility audit is scoped and quoted as a fixed piece of work; ongoing QA can be billed hourly, from £20 an hour, or run as part of a dedicated team. We look at your release process first, so we do not quote for testing you do not need.

No. Automate the checks you need on every release — sign-in, payments, the core journeys — and anything tedious to repeat by hand. Keep people on exploratory testing, usability and features that are still changing, where automated tests cost more to maintain than they save.

Both. For new suites we usually recommend Playwright, because it runs against Chromium, Firefox and WebKit — the engine behind Safari — and copes well with multiple tabs and users. If your team already has a healthy Cypress suite, we extend it rather than replacing it for the sake of it.

Yes. We need access to a test or staging environment, test accounts and whatever documentation exists. We learn the product through exploratory testing before writing any automation, and log findings in your existing tracker so your developers can pick them up straight away.

Yes. Automated scans catch only part of the picture, so we combine them with manual keyboard and screen-reader testing on the journeys that matter. You get a prioritised list of failures against WCAG 2.2 AA with suggested fixes, and we retest once they are resolved. Whether that meets your legal obligations is for you to confirm; we provide the evidence.

The ones your customers use. We check your analytics first and agree a list — typically current Chrome, Safari, Firefox and Edge, plus a spread of iPhones and Android phones including older, mid-range models. Real devices find problems that desktop browser emulation misses.

Yes. We script realistic user journeys, ramp traffic up to and beyond your expected peak in a production-like environment, and report where response times degrade and what gives way first — database, API or a third-party service — with recommendations to fix it.

In your own issue tracker, with steps to reproduce, expected and actual behaviour, environment details, screenshots or a recording, and a severity rating. The aim is that a developer can fix the issue without needing to ask a single follow-up question.

Yes. We write UAT scripts in plain language for the people who know the business, run the sessions with them, log what they find and track each issue to closure. UAT is where your team confirms the software does the job — it should not be where basic bugs are found for the first time.

Yes. We start with end-to-end tests on the journeys that would hurt most if they broke, then add unit and integration tests around the code that changes most often. Coverage grows where the risk is, not evenly across the codebase, so you get protection early rather than after months of test writing.