QA and test automation
Testing that tells you something. Manual QA where judgement is needed, automated suites where repetition is, and a pipeline where a failing test actually stops a release.
What we do
Manual QA
Test plans written from your requirements, exploratory sessions on real devices and browsers, and defect reports a developer can reproduce from the first read.
Test automation
End-to-end suites in Playwright that run in continuous integration on every change, plus API-level tests that are faster and less brittle than driving the UI.
Release gating
A pipeline where a red suite blocks the deploy, and a failure notifies the developer who can act on it rather than a channel nobody reads.
Accessibility checks
Automated axe checks on every component and manual keyboard and screen-reader passes on the flows that matter.
Rules we apply
- Every bug fix ships with a test for its class, written against the general failure rather than the single reported case, and pushed to the broadest layer that can catch it.
- The database is never mocked. Integration tests run against a real database in a container, because the bugs that reach production live in the gap a mock hides.
- Tests assert specific failures, not "an error happened". A test that passes for the wrong reason is worse than no test.
- Coverage is measured and may not regress, and browser suites run on a schedule against a built application rather than a development server.
Working with your developers
A QA engineer from our team can join your existing process: your tracker, your definition of done, your release cadence. We are also happy to start with a one-off audit that tells you where the coverage gaps are and what the cheapest first automation would be, before you commit to anything longer.
Want to know where your test coverage actually stands?
Send the repository or a description of your release process. You get a written assessment and a first automation plan within one business day.