Mindset

Quality isn’t a phase of software delivery; it’s a way of thinking.

I’ve spent 12 years testing one assumption: that better automation means better quality. The answer, it turns out, is it depends. And what it depends on is everything teams usually skip: the context, the risk, the engineering culture, and what “quality” actually means to the people who use the software.

That question, what does quality mean here?, shapes everything I do. I help engineering teams build confidence into the way they deliver software, not by adding more checks, but by helping them think more clearly about what they’re checking and why it matters.

I’ve coached more than 1,000 engineers, reached over 10,000 professionals through conferences and workshops, and spent 12+ years inside payments, CPaaS, ERP, and media companies. The frameworks I use aren’t theoretical. They come from real teams, real constraints, and real failures.

Image sourced from the web

Quality is built long before the first test runs.

What I believe

Automation should create confidence, not coverage.

A green pipeline that nobody trusts isn’t progress. I optimize for the team’s confidence in what ships, not the percentage of steps that run automatically.

When a team had 80% coverage but still deployed with anxiety, we didn’t add more tests. We rebuilt the suite around the signals that actually correlated with production incidents. Deployments went from twice-weekly fear to daily calm.

AI should amplify engineering judgment, not replace it.

AI is very good at generating tests and very bad at deciding which ones matter. That judgment (which scenarios are worth exploring, which risks are worth covering) stays with the engineer.

Teams that hand test generation entirely to AI end up with thousands of tests that take an hour to run and tell them nothing useful. The teams I’ve seen succeed use AI to explore edge cases they didn’t think of, not to automate the thinking they should be doing themselves.

The highest leverage comes from enabling teams, not heroics.

One engineer catching bugs doesn’t scale. A framework, a coached team, or a platform that catches bugs without you. That scales.

The most impactful work I’ve done wasn’t fixing bugs. It was building the coaching program, internal testing framework, or shared platform that let 50 engineers find their own bugs without needing me in the room.

Great metrics change conversations, not dashboards.

If a metric doesn’t change what a team argues about in planning, it’s decoration, not data.

I’ve seen teams track 40 quality metrics and still ship with anxiety. When we cut to 3 (deployment frequency, change failure rate, and mean time to recovery), planning meetings changed completely. Teams started shipping faster because they finally knew what “safe” looked like.

Great testers ask better questions before writing better test cases.

The test case is the easy part. The skill is knowing what to be suspicious of: which assumptions haven’t been tested, which edge cases the design ignores, which users the team forgot to model.

The best testing sessions I’ve seen didn’t start with a test plan. They started with someone asking “what would have to be true for this to work?” That question usually surfaces more useful test ideas in 10 minutes than a day of planning.

Context matters more than convention.

Best practices assume every team faces the same risks. They don’t. The right strategy depends on what you’re building, who it’s for, and what happens when it breaks.

I’ve worked on a payments platform where a single escaped bug could freeze thousands of transactions, and on an internal analytics tool where a broken chart just got a Slack message. The same automation strategy wouldn’t work for both. Anyone who says it would is selling a process, not a solution.

Quality strategies have to evolve or they become wrong.

Testing contexts shift. Teams change, products grow, risks move, users evolve. A strategy written at kickoff that looks identical six months later was not preserved because it was right. It was forgotten.

I have worked with teams whose regression suite passed every run while new failure modes went uncovered because the product had outgrown the strategy. The suite was not wrong when it was written. It was just never updated. Treating a quality strategy like living code, something that gets refactored alongside the system it covers, was the shift that fixed it.

The Context-Driven Quality Framework

Build confidence by understanding the system, not just testing it.

A practical framework for designing quality strategies that adapt to changing products, teams, and risks.

UNDERSTAND

Context

Map the system before touching it. Know what the product does, who depends on it, and what failure costs, before writing a single test.

Formed atNess Technologies

UNDERSTAND

Risk

Find the blast radius. Identify what can go wrong, how likely it is, and whether you’d even know, then test where it matters most.

Formed at8x8 International

DESIGN

Strategy

Design for your context. Build a testing approach around your team’s skills, your product’s risks, and your release cadence. Not a template.

Formed atXendit · 8x8 International

↻ Each Release

LEARN

Confidence

Ship knowing why it’s ready. Real confidence comes from understanding the risk, not from a green pipeline you no longer trust.

Formed atWorks Applications · 8x8 International

LEARN

Signals

Measure what moves the needle. Replace coverage vanity metrics with signals that tell you whether you’re confident to ship.

Formed atGracenote · 8x8 International

DESIGN

Enablement

Give every engineer leverage. Build the tools, platforms, and shared practices that make quality everyone’s responsibility.

Formed atZycus Infotech · Xendit · 8x8 International

↻ Context shapes quality. Quality creates confidence. Confidence evolves with every release.

The Context-Driven Quality Framework is a practical model for helping engineering teams move from understanding their product to shipping with confidence, through context, risk, strategy, enablement, and meaningful signals.

In practice

Automation should create confidence, not coverage.

The decision

Rebuilt a team’s test suite around the signals that correlated with production incidents instead of maximising coverage percentage.

The outcome

Deployment frequency doubled. Release anxiety disappeared. The QE team spent less time maintaining tests and more time exploring edge cases.

The highest leverage comes from enabling teams.

The decision

Built an internal quality coaching program instead of scaling QE headcount to meet growing demand.

The outcome

1,000+ engineers coached across multiple companies. Defect escape rate dropped without adding QE roles, because engineering teams owned the quality conversation.

Great metrics change conversations, not dashboards.

The decision

Replaced a 40-metric quality dashboard with 3 signals tied to release confidence.

The outcome

Sprint planning changed immediately. Teams started discussing risk instead of reporting on coverage, and shipping faster as a result.

How my thinking changed

Ideas that shaped my thinking

There are no best practices, only good practices applied in context.

James Bach · Creator of Rapid Software Testing

This idea dismantled years of cargo-culted process for me. The moment I stopped asking “what’s the industry best practice?” and started asking “what’s the right practice for this team, this product, this risk?”, everything got more interesting.

Testing is questioning a product in order to evaluate it.

Michael Bolton · Co-author of Rapid Software Testing

This definition changed my relationship with automation. Automation executes checks, and that’s valuable. But testing is the act of inquiry: asking what could be different, wrong, surprising. Machines can’t be curious. Engineers can.

Software design is an ongoing activity, not a one-time event.

Martin Fowler · Pioneer of refactoring and evolutionary design

Evolutionary design gave me the language for why quality strategies decay. They’re not written once. They’re maintained, adapted, and refactored as the system and team change. A strategy that can’t evolve is already legacy.

Testing is an empirical, technical investigation.

Dr. Cem Kaner · Co-author of Testing Computer Software

Kaner framed testing as a discipline of inquiry, which meant it had to have rigor, not just thoroughness. Good testing isn’t about running more cases; it’s about learning more reliably.

Quality is value to some person who matters.

Jerry Weinberg · Systems thinker and author

The most useful definition of quality I’ve found. It’s not about conformance to spec, defect rates, or pipeline health. It’s about whether the right person gets the right value. If the software doesn’t solve the problem the user actually has, a green pipeline is just expensive theater. Everything I do traces back to that question.

Questions I’m exploring

Agentic testingAI engineeringMCPEngineering enablementQuality intelligenceDeveloper experienceObservabilitySoftware architecture

How will AI reshape exploratory testing?

Engineering

What does software quality look like when most code is AI-generated?

Teams

How do we measure engineering judgment, not just engineering output?

Leadership

What does quality leadership look like in AI-native engineering organizations?

Future

What skills will distinguish exceptional quality engineers five years from now?

Product

Can confidence become a measurable engineering capability?

Systems

How can engineering organizations continuously adapt their quality strategy as products evolve?

Let’s continue the conversation.

These ideas reflect how I think today. If something resonated, challenged your perspective, or sparked a new idea, I’d love to hear it.

Connect on Email Connect on LinkedIn