QA & testing
The QA pack you can re-run after every change, including changes we did not make.
Every project we build ships with functional and regression testing written against the specification. We also do this as a standalone engagement for systems we did not build: a written QA pack your own team can run going forward.
- Pricing
- Scoped
- Typical timeline
- Scoped
- Stack
- Playwright · Vitest · Lighthouse · Test checklists
The deliverable is as much the test pack as the pass or fail run. Each item is marked against a requirement with a result and a reason, so a future change either passes or points at exactly what broke.
What this covers
Functional test packs
Every requirement traced to one or more test cases, so a failed test tells you which requirement stopped holding rather than just which button broke.
Regression suites
The checks that matter most after any change — core workflows, permissions, and the edge cases that regress quietly.
Release validation
A release checklist covering the things audits catch: data integrity, permission drift, accessibility and performance baselines.
Runable by your team
Tests written so a non-engineer on your side can execute them and report results — not a black box only we can run.
What you get
- A written test pack mapped to your requirements
- A full pass/fail run with a reason recorded for each result
- Permission, data-integrity and accessibility checks
- A recorded walkthrough and a note on what was not testable
- A re-run after fixes, with the delta documented
Stack
- Playwright
- Vitest
- Lighthouse
- Test checklists
We use a small, well-understood stack deliberately. Fewer surprises, faster decisions, and estimates that hold.
Common questions
- Do you test software you did not build?
- Yes — that is the standard case for a standalone QA engagement. Inherited code, a vendor deliverable, or a system about to be handed to a new team all benefit from a written, re-runnable pack.
- What makes the pack 're-runnable'?
- Every test names the requirement it checks, the steps, the expected result, and what a pass or fail means. Your team runs it without us, after any future change — including changes made by somebody else.
- How long does a typical review take?
- It depends on the size of the system and how much of it is reachable. We scope it from a call and a look at the requirements or the code, and quote a fixed price against that scope.