Postman and API testing at a QA interview: what to know and practise
Postman questions expose the gap between knowing API words and actually sending requests. The interviewer wants to see whether you can inspect a response, not just click Send.
- Method and URL
- Auth and headers
- Body and parameters
- Status, schema and data
What you should be able to do in Postman
Create a request, choose GET or POST, add query parameters, send JSON in the body, add an Authorization header and read the status code and response body.
For interviews, this is more important than advanced automation. A candidate who can reason about one response is stronger than one who memorised tab names.
The checks interviewers expect
For every API response check four layers: status code, structure, values and side effects. A 200 with the wrong total is still a bug; a 422 with the wrong field name is also a bug.
- Status code matches the situation.
- Required fields exist and have the right types.
- Important values match the request and requirements.
- Errors do not leak stack traces or internal paths.
- Repeated calls do not create accidental duplicates.
Auth checks in API testing
Always test the request with a valid token, without a token, with a broken token and with another user token. Many serious API defects hide in that last case.
If the endpoint returns data, ask whose data it is. Authentication only says who you are; authorization decides what you may see.
Typical Postman interview mistakes
The common mistakes are sending only happy-path requests, ignoring the body after seeing 200, forgetting headers and not saving the exact request that reproduced the defect.
A good habit: after every suspicious response, copy method, path, body and response into notes. That is already half of a bug report.
Practice task before the interview
Take any training API and test one endpoint with valid data, missing required field, wrong type, boundary value, no token and another user object id.
If you can explain each expected response and write one bug report from the result, you are ready for most junior Postman questions.
Real assertions in Tests
Each test should name the promise it protects. Separate assertions localise failures faster than one large block. Verify status and response type first, then schema and business values, and only then store an id for the next request.
The script below does not prove an order is fully correct, but it gives a useful minimum signal: valid JSON, required fields, a positive total and an id that can be chained safely.
pm.test("order created", () => pm.response.to.have.status(201));\n\nconst body = pm.response.json();\npm.test("contract and values", () => {\n pm.expect(body).to.have.property("id").that.is.a("number");\n pm.expect(body).to.have.property("status", "new");\n pm.expect(body.total).to.be.a("number").and.above(0);\n});\n\npm.collectionVariables.set("orderId", body.id);
Variables, chaining, Runner and CI
Use the narrowest scope: local for temporary secrets, data variables for a Runner row, environment for host values, collection for scenario data. Never commit live tokens in an exported collection. Tag created records uniquely and remove them in teardown when allowed.
- A pre-request script creates unique data or refreshes a token.
- Tests stores the response id only after validating the contract.
- The next request uses {{orderId}} and verifies the same object.
- Collection Runner repeats the flow with CSV or JSON data, including negative rows.
- Postman CLI or Newman runs the same collection in CI and exits non-zero on failure.
Follow-up questions interviewers ask
Be ready to explain why a 200-only test is weak, where a secret should live, how 401 and 403 differ, what happens when POST is retried after a timeout, and how to test pagination, rate limits and another user’s object id.
A strong candidate names the oracle: OpenAPI, an acceptance criterion, an RFC, a follow-up GET, database state or an agreed business rule. Without an oracle, a polished script merely freezes current behaviour.
Common Postman questions
Must a manual QA learn JavaScript for an interview?
Usually it is enough to read JSON, declare a const, access a field and write pm.test with pm.expect. Explaining what the assertion protects matters more. A specific role may require more.
Does Postman replace database verification?
No. An API exposes the external contract. A critical side effect may need a follow-up GET, event, database record or integration check.
How does Collection Runner differ from Newman or Postman CLI?
Runner executes interactively in Postman. A CLI runs the collection in a terminal and CI, where environments, reporters and exit codes matter. The assertions should stay the same.
Postman is not the skill by itself. The skill is noticing what the server actually promised and what it actually did.