Contract Testing Isn't the Hard Part

Where Do We Start?

Most teams aren't avoiding contract testing because they think it's of little value. They're not starting because starting takes time that offers little or no reward. Features ship. Testing infrastructure doesn't show up in a sprint review.

So contract testing stays on the backlog. Never quite making it into planning. The backlog wallflower.

How can quality coaching help overcome that inertia?

A Quality Coach in your repo

Recently, I ran an experiment. I built a test strategy skill based on my approach to risk, failure modes, and where testing matters. A skill in machine learning is a reusable set of instructions that encodes how to reason through a specific problem; think of it as a playbook you write once and run repeatedly. I ran it against two repositories I'd never seen. Teams I didn't know. Domain knowledge based on what existed in the repositories.

What came back wasn't "consider contract testing" or "integration testing would help here." It was specific: start with this contract, in this part of the system, because this is where business risk and technical failure modes concentrate. Not a recommendation. A starting point.

That alone would have been useful. But the output also surfaced integration failures the teams didn't have visibility on — not just prioritising known work, but pulling unknown risk into the light.

Two problems solved from a codebase I'd never read.

The skill draws the path

There's a concept I've written about before — the elephant and the rider. The rider knows the right direction. The elephant won't move without a clear path. Teams stuck on where to start aren't short of knowledge — they're short of a path. The skill draws the path.

Once that happens, the coaching conversation changes. You're no longer the person who spends weeks reading the code, building a mental model, and earning the right to say "start here." What you're doing now is helping the team understand the output, build confidence in the methodology, and act on it.

The skill works because it encodes a specific way of reasoning about risk — weighing business impact against technical failure mode, before making a recommendation. Generic prompts get generic answers. Encoded methodology gets specific ones.

What the skill can't do is what comes after. Getting a team started is one thing. What happens at six months — when the system has changed, the team has turned over, and nobody remembers why they started with that contract — is a different coaching conversation. That's where continuous feedback, adaptation, and auditing against measurable outcomes come in.

Ask yourself. What's stopping your teams from starting a quality improvement? Is it time? Is it know-how? Is it confidence?

That gap might now be encodable. The question is whether you've made your methodology explicit enough to encode it.

Most of us haven't. Not fully.