QA and test automation
Manual QA before a release, and automated tests that keep catching the same bugs after it.
QA is the other half of the same job. A security finding that comes back three releases later is a regression, and the fix for regressions is a test that fails when the bug returns. We test releases by hand where judgement matters and write automated tests where repetition does.
What we test
- Release testing against written test cases, on the browsers and devices your users have
- End-to-end browser tests for the flows that make money or hold data: sign up, checkout, payroll, export
- API tests for contracts, validation and error handling
- Regression tests for each security finding we report, so a fix stays fixed
- Running the suites in your CI so a failing test blocks the merge
- Bug reports with steps to reproduce, expected and actual result, and a screenshot or recording
What do you get at the end?
- Test cases and a test report per release
- Automated tests committed to your repository, in your stack
- A short handover so your developers can extend the suite
How does the engagement run?
Scope and written authorization first, then testing inside the agreed window, the report, and a retest of what you fix. The steps are the same for every service and are set out on the approach page.
Frequently asked questions
Which test frameworks do you use?
The ones your team already uses, so your developers can maintain the tests after we leave. Where a project has no test setup yet, we propose one, explain the choice, and agree it with you before writing tests.
Do you replace our QA team?
No. We can run release testing when you have no QA team, or work alongside an existing one. The automated suites are committed to your repository with a short handover, so your developers can run and extend them without us.
Can automated tests cover security?
Partly. A regression test can prove that a specific fixed issue, such as one user reading another user's record, stays fixed. It cannot find new kinds of vulnerability, which is why we pair automation with periodic penetration testing instead of treating one as a replacement for the other.
Tell us what you want tested.
A short call, then a signed scope. No testing before that.