02 /QA & Manual Testing
API Testing
Functional verification of an API as a product surface: does it do what its documentation says, does it fail in a way a caller can handle, and does it still honour the promises made to whoever integrated last year. This is the human-judgement layer, not the automated suite.
What you get
Contract conformance findings
Every documented endpoint exercised against what the documentation claims, with the divergences written up. Documentation that has drifted from the implementation is itself a defect, and it is the one integrators hit first.
Error semantics review
What happens on bad input, missing fields, wrong types and unauthorised calls. A well-behaved API distinguishes these clearly; one that returns 200 with an error body, or 500 for a validation failure, pushes the cost onto every client.
Backwards-compatibility checks
Whether a change is breaking, tested rather than asserted in a review comment. Added optional fields, changed enum values, tightened validation and altered pagination all break callers in ways that look harmless in a diff.
Boundary and data-shape cases
Empty collections, single items, very large payloads, unusual characters and the edges of every numeric range. These are where serialisation quietly changes behaviour and where a caller receives something it cannot parse.
How it runs
- 01
Establish the contract
We work from whatever exists — a specification, a collection, a set of examples — and where nothing does, we write down the observed behaviour so there is something to test against and something to hand your integrators.
You provide: Access to a non-production environment and any existing documentation
We produce: A written statement of expected behaviour
- 02
Exercise the surface
Each endpoint is called across its documented behaviour and well past it, with attention to how failures are reported rather than only to whether success works.
We produce: Findings against the contract · Defect reports
- 03
Test the change, not just the state
Where a release is in flight, the current version is compared against the previous one so anything breaking is identified as breaking before an integrator discovers it.
We produce: A compatibility assessment for the release
Where this stops
- Not an automated API suite running in your pipeline. That is genuinely more valuable long term, and it lives under test automation because it is a build rather than a test cycle.
- Not API security testing. Authorisation boundaries, injection and the OWASP API risks are a separate discipline with separate methods, and finding functional bugs does not find those.
- Not load or throughput testing. We report correctness, not capacity; capacity needs instrumentation and a controlled environment.
- Not API design consultancy. We will tell you where the contract is inconsistent or hostile to callers, but redesigning it is your architecture decision to make.
Related reading
- Quality assurance
How to write a bug report a developer can act on
A defect report is a handover of an unfinished investigation. Most of them fail in the same three places, and none of the repairs involve a longer template.
- Test automation
Test data management: five strategies and what each one costs
How a test obtains the state it needs decides whether a suite survives parallel execution. Five approaches, the failure mode of each, and the problems nobody puts in the estimate.
- Test automation
When to automate a test, and when the answer is no
Not a philosophy of automation but a decision taken one case at a time. Five signals, four possible verdicts, and why "keep it manual" is not the losing option.
FAQ
API Testing questions we hear often
We have no API documentation. Can you still test it?
Yes, and the documentation becomes a by-product. Without a specification we establish expected behaviour from the implementation, your team and what a reasonable caller would assume, then write it down. That artefact is often worth more than the defect list, because it is the thing that lets you say whether a future change is breaking.
Is this different from testing through the user interface?
Substantially. The interface only ever sends the requests it was built to send, so testing through it exercises a narrow, well-formed subset of what the API accepts. Calling the endpoint directly reaches the malformed, out-of-order and unauthorised cases that real integrators will produce by accident within a week.
How do you decide whether a change is breaking?
By running the previous contract against the new implementation rather than by reading the diff. Plenty of changes that look additive are not: tightening validation, changing a default, reordering results or altering an error code all break callers that were relying on the old behaviour, and none of them look dangerous in review.
Should this be automated instead?
Eventually, for the parts that are stable. Contract checks are repetitive and machine-friendly, so they are good automation candidates once the shape has settled. What stays manual is judgement: whether an error message is actually usable, whether the documentation matches intent, whether the design will hurt the next integrator.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.