What I Do

I do

  • QA architecture. I design how a system is going to be tested before there’s anything meaningful to test in it. That includes testability requirements, environment topology, data strategy and the contract between engineering and quality.
  • Test automation strategy. Where automation pays back, where it doesn’t and what the suite should look like twelve months out. Tool choice comes second; the question of what is worth automating comes first.
  • Release engineering. Dependency-aware pipelines, quality gates with explicit proceed and block conditions, blue/green deployment and rollback protocols. A release should be a decision your pipeline can defend, not a Friday-night ritual with a rollback plan nobody has rehearsed.
  • Delivery management. Removing the structural reasons your releases are late, painful or both. Process redesign rather than process compliance — and a written reason for every change.
  • QA capability building. Hiring pipelines with designed assessment exercises, role grading, onboarding standards, skill matrices. The goal is a department that still works the week after the person who built it stops answering messages.
  • AI in the QA pipeline. Agentic and AI-assisted workflows built against your real tickets, code and test cases, then tuned until the output is worth a person’s time. Every one of them keeps a human at the decision point.
  • Cross-team coordination. Getting QA, product, engineering and operations to share one definition of “done”. Often the cheapest fix in the building.
  • Tool selection. Right tool chosen after complete analysis of processes, teams and goals — chosen second, after the question of what you’re actually trying to measure is answered.
  • Metrics that mean something. Perception matters and I help find and build the ones that benefit processes and the business — not the ones that just fill a dashboard.

I don’t do

  • Manual test execution. I’ll help your team do it well, and design the system so they need to do less of it. I won’t be the person clicking through your admin panel.
  • Test case reviews. If you want someone to rubber-stamp a backlog of test cases, that’s not me. What’s the point in reviewing generated test cases for possibly generated ACs? Yep, I think the same.
  • ISTQB cert farming. Certificates are not a substitute for thinking. If your QA strategy depends on counting them, that is the problem.
  • Batshit metrics. Test counts, line coverage percentages, “passes per sprint” — none of those numbers tell you whether the software works. I won’t help you collect them, and I’ll argue against gathering and analyzing them.
  • Autonomous AI. Nothing I build merges a pull request, closes a ticket or ships a release on its own. If an agent can act without a person deciding, you haven’t automated the work — you’ve automated the blame.

What this has actually produced is on /proof/. If it sounds like what your team needs, get in touch.