Manual testing by developers
isn't a QA strategy.
A 4–8 week fixed-price engagement that builds a testing practice from scratch — strategy, regression suite, CI integration, and a process your team can own without a consultant.
Starting from zero isn't
a temporary state. It compounds.
Most engineering teams start without a QA function. Developers test their own code, someone manually clicks through the app before release, and for a while that works. Then the product grows. The team grows. The release cadence increases. And the informal approach that worked at ten features starts failing at fifty.
The problem isn't that the team doesn't care about quality. It's that there's no infrastructure for it. No strategy that defines what gets tested and why. No regression suite that catches regressions. No CI integration that makes test results visible. Every new feature adds to the risk surface with nothing to offset it.
The QA Foundations Programme builds that infrastructure in 4–8 weeks. At the end, your team has a strategy, a suite, and a process they own — not a dependency on a consultant.
Five deliverables. Everything your team needs to own QA.
Test strategy document
Risk-based. Maps what gets tested, how deeply, and why — to your actual product and release cadence. Not a template. Not a framework. A strategy specific to this product.
Regression suite
Automated tests covering the critical user journeys — the paths that, if broken, would cause a real problem. Web, API, or mobile depending on your stack. Built to be maintained by your team, not by a specialist.
CI pipeline integration
Tests run automatically on every PR and every main branch merge. Pass/fail results are visible in the pipeline. Nobody ships without knowing whether the critical paths are green.
Bug triage process
A defined process for how defects are logged, categorised (severity, priority), and resolved. Set up in your existing issue tracker. Simple enough that developers will actually follow it.
Handoff session
A structured walkthrough of everything built — the strategy, the suite architecture, CI setup, and triage process. Your team leaves able to maintain and extend it without Stuart.
Four phases. 4–8 weeks. Fixed scope and price.
Discovery & risk mapping
Week 1. Review the product, the stack, and the team. Map the highest-risk areas. Agree the tooling. Produce the test strategy document.
Suite build
Weeks 2–4 (or 2–6 for larger scope). Write and validate the regression suite covering agreed critical paths. Review with the team as it's built — not as a surprise at the end.
CI integration & process
Final week. Integrate tests into CI. Set up the bug triage process. Run the suite end-to-end in the pipeline. Fix any configuration issues.
Handoff
Structured walkthrough session with the team. Documentation handed over. Questions answered. Stuart's involvement ends — your team owns it from here.
The handoff isn't an afterthought.
It's the point.
A testing practice that depends on a consultant isn't a practice — it's a dependency. Every decision in this engagement is made with the handoff in mind. Tool choices, framework architecture, naming conventions, documentation — all chosen because your team can maintain and extend them without specialist support.
Chosen for your team
Playwright (default for web), Cypress, Appium (mobile), or API-focused — chosen based on your existing stack and team capability, not Stuart's preference.
What you already use
GitHub Actions (default), GitLab CI, Azure DevOps. Integrated into the pipeline you already have — no new infrastructure required.
Critical paths, not full coverage
The initial suite covers critical user journeys and highest-risk flows — not the entire product. That's the right starting point: high confidence where it matters most, expandable from there.
✓ Developers test their own code before release
✓ A QA Audit has confirmed you need to build from scratch
✓ You're scaling and need quality infrastructure in place first
✓ You want fixed scope and a fixed price — no surprises
Fixed-price. Scoped precisely before we start.
- ✓Test strategy document
- ✓Regression suite (critical paths)
- ✓CI pipeline integration
- ✓Bug triage process
- ✓Handoff session — team walkthrough
Price range is driven by team size, codebase complexity, and stack. Confirmed with a fixed figure after the discovery call — no variable costs.
What people ask before they book the call.
- How much does the QA Foundations Programme cost?
- Between £6,000 and £10,000, fixed-price and confirmed after the discovery call. The range is driven by team size, codebase complexity, and stack. No variable costs after the scope is confirmed.
- How long does it take to build a QA practice from scratch?
- 4–8 weeks, depending on team size and starting point. The programme is structured to minimise disruption to ongoing engineering work — most of the heavy lifting happens remotely, with short check-ins each week.
- What do we get at the end?
- A test strategy document, a working regression suite covering critical paths integrated into CI, a bug triage process, and a handoff session so the team can maintain and extend everything independently — not a dependency on PrsnQA to keep running.