Judgement is what you are buying

Proposals get priced as throughput: a number of testers, a number of cycles, a number of cases. Those figures are easy to line up side by side, which is why suppliers lead with them. Two teams can run the same number of cases against the same product and come out with completely different results, so the count on its own tells a buyer almost nothing.

What separates them is where they look. Test design is a run of decisions about what deserves attention. Which flows carry the money. Which integration is most likely to be lying about its state. Which combination of inputs nobody thought to write down. None of that is in the requirements document; it comes from having watched software fail before.

Failure modes travel between industries much better than the industries themselves do. A payment taken twice because a retry fired on a slow response is the same defect in a retail checkout, an insurance premium or a utility bill. A reconciliation that silently drops a record when the batch runs past midnight looks the same in logistics as it does in banking. A permissions model that leaks between two users at the same client has the same shape in a health product and a school platform.

Someone who has seen the retail version knows to go looking for the banking one, and knows it in week one rather than in the third cycle. No methodology teaches that and no certificate demonstrates it. It comes from having tested enough different products for the patterns to start repeating.

It is also why domain knowledge tends to be oversold. Knowing an industry’s vocabulary helps you talk to its stakeholders, and most testers pick that up in a fortnight. Knowing how software breaks is the part that takes years, and it is the part that carries over from one client to the next.

• The test plan argues for its priorities instead of listing every feature at equal weight
• Someone asks what happens to a flow at month-end, or when the third party is down, before anyone has written it down
• A defect is raised with an explanation of the business consequence, not only the reproduction steps
• A risk that nobody asked about gets flagged, because it is the one that will cause the rollback
• Somebody is willing to say "this is not ready" on a date that has already been announced

Before any contract exists, ask a prospective supplier how they would prioritise your product. Not a methodology slide: your product. What would they test first, and why that rather than the thing next to it. Ten minutes of that will tell you whether you are buying judgement or headcount.

Then ask who will actually do the work, and whether that person is in the room for the conversation you are having now. In a bench model the answer is usually no, and the profile who turns up is whoever happened to be free that month.

One caveat on all of this. A testing supplier should not be setting priorities on its own. That gets agreed with the people who know what the business cannot afford to get wrong, which means the client’s subject-matter experts and key stakeholders. The supplier brings the failure modes to that conversation and argues for them; it does not settle the question by itself.