Manual and exploratory testing
Scripted coverage for the flows that matter, plus unscripted poking at the places that look fragile. Most of the interesting bugs turn up in the second kind.
Software testing & QA
Find the bugs before your users do
I've had responsibility for the testing at a start-up, and testing is what I do best. I'll tell you what's broken, how to reproduce it, and whether it should block your release.
What I do
Testing that covers the whole release, not just the happy path
Developers test what they built the way they meant it to be used. That's not a criticism, it's just how knowing a system works. I come at it from the outside.
Regression testing
Re-testing what already worked, after every change. Tedious to do properly and the single most common thing small teams skip.
Test planning and documentation
A written plan covering scope, environments, cases and the risks being prioritised. It means the next round of testing repeats this one instead of starting over.
Bug reports your developers can use
Steps to reproduce, environment, severity, evidence. I've been the developer picking these up too, so mine are written to be acted on straight away rather than filed.
Browser and device compatibility
Checking the site behaves on the browsers and screen sizes your customers actually use, not only the one it was built on.
API testing
Requests, responses, error cases and the edges. Useful when the frontend looks fine but something underneath is quietly wrong.
Test automation
Automated suites covering your critical paths, in whichever framework suits your stack, so they're checked on every release instead of whenever someone remembers.
How it works
You'll always know what I've tested and what I found
No black box. You get the plan before I start and the findings as they come in, not a report at the end with no time left to act on it.
- 01
Discovery
I learn the product, who uses it and how often you release. Then we agree what's worth testing and what isn't.
- 02
Test plan
Scope, environments, cases and priorities, written down. You approve it before any testing starts.
- 03
Testing
I work through the plan across browsers, devices and APIs, and spend extra time wherever the risk looks highest.
- 04
Reporting
Reproducible reports with severity and evidence, delivered as I find things rather than saved up for the end.
- 05
Retest
Once fixes land I verify them, re-run regression and give you a straight answer on whether it's ready to ship.
Pricing
By the hour, or fixed price for a defined scope
Hourly suits ongoing work and filling gaps. Fixed price suits a release with a clear end date. I'll tell you which one fits after we've talked about the project.
Starter
Fixed priceOne focused pass over a feature, a release, or a sprint's work.
- Manual functional testing
- Bug reports with steps to reproduce
- One round of retesting
- Summary of what was covered
Launch-Ready
Fixed priceFull coverage before a launch or a release you can't afford to get wrong.
- Regression and compatibility testing
- Written test plan
- API testing
- Retesting until fixes hold
- A clear go or no-go on the release
Ongoing
Custom scopeTesting built into your release cycle, for teams shipping regularly.
- Regression testing each release
- Automated tests for critical paths
- Continuous bug tracking and retesting
- Monthly summary of quality trends
Who this is for
Teams that need testing, not a testing department
Hiring a full-time QA engineer is a big commitment, and most small teams can't justify it. This is the version you can.
Teams with no dedicated tester
Your developers are testing their own work between other tasks. Things get missed, and nobody has time to write down what was covered.
Teams with a launch coming up
A release with real money or reputation behind it, and a nagging feeling that clicking through it once on a Friday isn't enough.
Got something to ship?
Tell me what you're releasing and when. I'll come back with a testing plan and a price, usually within a day.
Request a quote