About the role
Most testing asks whether the button worked. Here the harder question is whether the number under the button is right, and whether it is the same number it was last week for a reason somebody can name.
So this is two jobs held by one person. The ordinary one: the application, the API, the flows, the browsers, the regressions. The unusual one: the outputs themselves, checked against reference cases and against their own history, so a silent shift in a model or an upstream source is caught here rather than by a client.
What you will do
- Own the automated suite end to end: unit, integration, API contract and browser level, running on every change rather than before a release.
- Build and maintain reference cases with known correct answers, and gate releases on them, so a change that quietly moves an output has to be justified before it ships.
- Regression-test the numbers, not only the interface. Compare outputs across versions, flag drift, and make the difference explainable rather than merely visible.
- Test the ingestion path where most silent failures start: a source that changes shape, a field that stops arriving, a record that stops updating while still looking fresh.
- Break things deliberately: bad input, missing data, partial failure, timeouts, and the states nobody designed for.
- Verify accessibility, responsive behaviour and the paths people actually take, across real browsers and real devices.
- Keep the report of what is covered and what is not honest, including when the answer is uncomfortable.
- Reproduce and triage what customers report, and turn each one into a test that would have caught it.
What we look for
- You write test code, in JavaScript or TypeScript or Python, rather than only executing test plans.
- Browser automation you have kept green over time, in Playwright, Cypress or the equivalent, including the flakiness that comes with it.
- SQL, well enough to check a result against the database rather than against the screen.
- API testing: contracts, edge cases, error paths, and the difference between a 200 and a correct answer.
- The instinct to distrust a passing suite, and the persistence to find the case that does not pass.
Nice to have
- CI pipelines, and making a suite fast enough that nobody is tempted to skip it.
- Testing systems whose output is numeric or statistical rather than exact.
- Load and performance testing.
- Security testing basics: injection, authorisation boundaries, exposed data.
- Accessibility standards in practice, not just in a checklist.