A business analyst who can send an HTTP request is a different kind of analyst. Not because API testing is the job, but because the act of writing a request forces every ambiguity in the specification to the surface immediately. You cannot send a vague request. The tool will not let you.
Here is the whole practice, as I use it on client work.
Write the request before you write the requirement
Take the feature you are specifying and try to express it as a call. Method, path, body, expected status, expected response shape. Within about two minutes you will hit a question the specification does not answer.
Is the customer identifier in the path or the body? Is the date an ISO string or an epoch? When a field is absent, is that different from the field being null? What comes back on a duplicate submission — a conflict, or a success with the original record?
None of those are technical questions. They are all business questions wearing technical clothes, and every one of them is cheaper to ask in a requirements workshop than in a defect report six weeks later.
Build the collection as a specification artifact
I keep a Postman collection alongside the BRD for every feature that has an API surface. It has one folder per user-facing capability, and inside each folder:
- The happy path, with the exact payload from the specification.
- Each business rule that can reject the request, one request per rule.
- The auth cases: no token, expired token, valid token for the wrong role.
Environment variables carry the base URL and the token, so the same collection runs against dev, staging and UAT without editing a single request. When the developer says it is ready, I do not read the code. I run the folder.
What this changes in the conversation
The interesting shift is not that I catch more defects. It is that the arguments get shorter. "The endpoint returns 200 with an empty array when the customer has no orders, but the specification says it should return 404" is a sentence with no room for interpretation. Nobody has to defend an opinion. We look at the rule, decide which behaviour we want, and I amend the document.
That is also why I keep the negative cases in the collection even after they pass. They are executable acceptance criteria. Six months later, when somebody changes the validation layer, the folder tells us what we agreed to in a way the document alone never could.
A short version of this ran on X
I posted a condensed version of this argument and it started a decent thread about where the analyst's job ends and QA's begins:
And the long-form piece, with the full collection structure, lives as an Article on my X profile:
Article on X · @idhruv.techThe analyst's Postman collectionFolder structure, environment setup and the token script I reuse on every client project.5 August 2026· 7 min readRead on X →Where to stop
This is not a case for analysts writing automated test suites. Performance testing, contract testing, CI pipelines — that is engineering work and it should stay there. The line I hold is this: I test what I specified, against what I specified, before I sign off that it matches. Anything past that belongs to somebody whose job it is.