Engineering services
Testing & QA
We try to break it before your customers do: on real phones, real browsers, and under the kind of traffic a busy day brings.
Part of your product’s journey
Of the eight stages we run, this service covers Test. We also run the others.
What this makes possible
Every team tests. The question is whether the testing is repeatable. Checking by hand before a release finds today’s bugs and forgets them by the next release. The same fault returns three months later, and nobody notices until a customer does. Automated tests are memory: a mistake, once found, cannot come back quietly.
Our approach in more detail
We build that memory in layers, and the shape matters. Many small, fast tests over the calculations and rules that are easy to get wrong. Fewer, slower tests that run the real pieces together against a real database, rather than a stand-in that agrees with whatever the code does. And a small number of tests that drive the product from end to end the way a customer would. Those cover only the journeys that genuinely matter: signing up, paying, the one workflow the business runs on. A full set of end-to-end tests covering everything is slow, unreliable and eventually ignored, which is worse than having none.
Automation is not always the right tool. Visual judgement, poking around to see what breaks, behaviour peculiar to one device, and whether a flow makes sense to a person — all of that needs a human. So we do both, and we close the loop. Anything found by hand that could happen again gets an automated test. Over time, the checking by hand concentrates on new work rather than re-checking old work.
What you get
- Automatic checks on each piece, and on the pieces working together
- Checks that connected systems still agree on what they send
- Full run-throughs of the journeys that matter most
- Verified on real browsers and real devices
- Where there is a busy day to plan for, traffic simulated before it arrives
- Every past bug added to the checks, so it cannot return
How we get there.
- 01
Assessment and risk map
We look at what exists: how much of the code the current tests cover, which tests fail at random, and where defects have actually come from. Then we rank features by what it would cost if they failed. Payment and login sit at the top. A rarely used admin export does not. This ranking decides where the effort goes, because covering an entire application evenly is neither achievable nor useful.
- 02
Foundations and the fast tests
First the setup that makes tests cheap to write: the framework and the ready-made sample data. Then cover over the business rules, the calculations, the checks on what users type in, and the permission rules. These run in seconds, and they catch the errors otherwise found by a customer looking at a wrong number.
- 03
Tests against the real pieces
Services tested against a real database and the real components beside them, with outside providers replaced at the point where the request leaves your system rather than faked deeper in the code. We also add tests that pin down the agreed shape of requests and responses between your system and the apps or sites that use it. A change that breaks one of them then fails automatically, rather than surfacing in somebody else’s release.
- 04
End-to-end and cross-device
A deliberately small set of tests that drive a real browser through the critical journeys. They are written to be stable. That means waiting until the application is genuinely ready, rather than pausing for a fixed number of seconds. And using data we put there on purpose, rather than whatever happens to be lying around. Then checking by hand across the browsers and devices your analytics say your customers actually have.
- 05
Load testing and automation
Realistic traffic run against a private copy of the system to find where it starts to bend, expressed as a number you can plan against rather than a pass or a fail. Everything is then wired in so it runs automatically on every change, with clear reporting. A failing build nobody trusts gets ignored within a fortnight.
A little more detail.
The process, the fit, and the questions worth asking before we begin.
Is this the right service for me?
- Not for you if you need a coverage percentage to put in a customer questionnaire. We will not pad the count with tests that check nothing, and a number produced that way tells you nothing about your risk.
- Not for you if the code cannot be tested without being restructured first and there is no appetite to restructure it. Business rules tangled into screen code can only be tested through the screen, which is slow and unreliable. Sometimes the honest first step is untangling it, and that is a different engagement.
- Not for you if the team will not maintain the tests. Tests left to rot become a wall of red everyone learns to ignore, and you will have paid for something that now slows releases down.
- Not for you if you have not launched and the product may change entirely next month. Testing a screen about to be replaced is paying twice.
- Not for you if you want us to sign off releases without the authority to stop one. Quality assurance that cannot say no is a formality, and we will not lend our name to it.
A worked example
Hypothetical scenario
Illustrative: a checkout that fails intermittently
Say roughly one order in fifty fails at payment and nobody can reproduce it. An engagement of this shape starts by making the failure visible, not by writing tests. We add logging that carries a single identifier through the whole journey, so one failed order can be followed from start to finish. That usually narrows it fast. The answer is often a timing problem. The payment provider’s automatic notification comes back before the order has finished saving, so the code handling it looks for an order that does not yet exist. The fix is one thing; the tests are the point. A test that fires that notification before the order is saved. A test that pins down the exact shape of the message the provider sends. A test that walks a real checkout on every release. And a load test running many checkouts at once against the same stock. Engagements of this shape run four to eight weeks to a set of tests the team trusts.
An illustration of our approach, not a delivered client project.
How long before we see the benefit?
The risk ranking and a first set of tests over the highest-risk paths land inside two weeks, and that is where the early defects turn up. A set of tests the team genuinely relies on, for an application of moderate size, takes four to eight weeks. Load testing adds one to two. The variable is how much the code has to be restructured before it can be tested at all.
Can you work alongside our existing developers?
That is the usual arrangement. We write the tests, wire them into your release process, and work side by side with your engineers so they can extend them. Testing works badly as a permanently outside function. The aim is that your team writes tests for new features while we handle the foundations, the harder layers and the load work.
What about a system with no tests at all?
We do not try to cover everything retrospectively; that is expensive and mostly wasted. The critical journeys get end-to-end cover first, which gives you a safety net immediately. Smaller tests are then added to each part of the code as it is touched for other reasons. New work gets tests from day one. Old code that has been stable for years and that nobody is changing is left alone deliberately.
How do you stop end-to-end tests being unreliable?
A small set of tests. References to page elements that do not change every time somebody redesigns a page. Waiting until the application reaches the expected state rather than sleeping for a fixed time. And test data we control rather than whatever is in the system that day. Any test that fails on and off is set aside and fixed, rather than re-run until it passes. A set of tests people keep re-running until they go green has stopped being a test.
Do you test manually on real devices?
Yes, on real hardware including deliberately older and slower phones, and on the browser and operating system mix your analytics actually show rather than a generic list. Checking by hand covers what automation is bad at: things that simply look wrong, whether a flow makes sense, and behaviour peculiar to one device. Anything found by hand that could happen again becomes an automated test.
Bring the pieces together
Tell us what you need to achieve. We’ll help you scope the work and see how it fits your wider product.