Contract testing
Also called: consumer-driven contracts, API contract tests
Contract testing checks that two services agree on the shape of the messages they exchange, without running the whole system.
A contract test verifies that a provider still returns what its consumers expect: the fields, the types, the status codes. It is quick, developer-owned and catches breaking changes before deployment.
It does not prove the journey works. A contract can hold while authentication, data, feature flags or the meaning of a field are wrong. That gap is covered by a small number of functional smoke checks that assert outcomes a user would recognise.
The division I recommend: developers own the contract tests, testers own the functional smokes, and a partner’s published contract is used as the expected result when testing an integration.