I'm a senior QA professional with twenty years of experience leading test functions across complex, high-stakes technology programmes. That spans enterprise pricing platforms, delegated underwriting systems, finance transformations & COTS implementation — at many companies, most recently including Liberty Insurance, Munich Re, Allianz,Convex and Tokio Marine Kiln.
What that time teaches you is the difference between testing that looks productive and testing that actually reduces risk. Most teams are good at the former: the metrics look healthy, the coverage numbers are high, and then something breaks in production that nobody saw coming. The real work is building the quality infrastructure — strategy, automation, release governance — that gives your team genuine confidence, not just numbers.
PrsnQA exists because senior QA leadership doesn't have to mean a full-time headcount commitment. I work as a fractional Head of Testing and QA consultant — embedded in your tools, your sprints, and your planning cycles — so growing engineering teams get the strategic oversight that was previously only available to enterprises. UK-based, working remotely across time zones.
How I approach the work
My starting point is always the risk profile, not the test suite. Before I touch a test case, I want to understand what a bad release looks like for your business — the financial exposure, the customer impact, the recovery cost. Most QA programmes I encounter are optimised for activity metrics rather than risk reduction. They measure coverage and velocity, not confidence. Making that risk visible is where the real work starts.
I work inside your existing tools wherever possible — your ticketing system, your CI/CD pipeline, your processes. The goal is always a quality practice your team can own and evolve independently, not one that depends on me being in the room.
The first 30 days
Every engagement starts with a structured onboarding period. In the first two weeks I shadow releases, read post-mortems, attend planning sessions, and map the gap between what the team believes about its quality and what the evidence shows. By week four there's a written assessment with specific, prioritised recommendations — and shared understanding of what we're building toward before anything changes.
A pattern I encounter regularly: a team with a large, maintained regression suite that's losing confidence in releases. The suite tests the right things by the original spec — but the product has drifted. New features accumulated without corresponding test coverage. The gaps aren't obvious until something breaks publicly. The fix is reconnecting the test architecture to the current risk profile. That takes judgement, not tooling.