1. What do you assert besides the status code?
Check the response's shape, required values, relevant headers, and the intended state change. A success code with an incorrect total or another user's record is still a failure. Postman's documentation explains how response tests can assert returned data; the important design decision is what correctness means for your endpoint.
Our practice contract is POST /orders: an authenticated user submits an item and quantity, and the service creates exactly one order with a server-calculated total. Define valid quantity bounds and currency behavior before writing assertions. Check the created order through an authorized read path rather than trusting only the response that claims it was saved.
2. How do you choose negative test cases?
Group cases by violated rule: missing required input, invalid type, boundary value, unsupported state transition, authentication failure, and authorization failure. Use a small representative set that exposes distinct risks. Sending hundreds of random malformed payloads does not replace a clear explanation of the contract.
For quantity, test the minimum allowed value, the value just below it, the maximum, and the value just above it. Include a non-integer if the domain only allows whole units. Verify that rejected requests do not create partial orders or consume inventory. The expected error status and body should follow the documented API contract, not personal preference.
3. How do authentication and authorization tests differ?
Authentication establishes who is making the request; authorization determines whether that identity can perform the action on the resource. In an interview, explicitly test a valid user attempting to access a different user's order. A test suite that checks only missing tokens leaves an important access boundary unexamined.
Use synthetic accounts in an authorized test environment. Create an order for user A, attempt access as user B, and verify the response and absence of unintended changes. Do not use real customer records for an exercise. Also check that diagnostic messages do not expose private order contents when access is denied.
4. How do you test retries without creating duplicates?
First determine whether the endpoint has an idempotency contract. For an order-creation API that accepts an idempotency key, repeat the same permitted request with the same key and verify the documented response and a single resulting order. Define what should happen when a key is reused with a different payload.
Our failure scenario is a request accepted by the server whose response is lost. The client cannot infer from the timeout alone whether creation happened. Test that ambiguity deliberately using a controlled test setup. A retry policy without a server-side contract may duplicate the operation, even if the client code looks robust.
5. What can go wrong with pagination?
Test empty results, the final page, invalid page parameters, stable ordering, and records added or removed between requests. Clarify whether the API promises a snapshot or a changing view. The correct assertions depend on that contract; not every pagination design can promise that concurrent writes are invisible to the reader.
For a small fixture of seven orders and a page size of three, predict three pages with sizes three, three, and one. Verify identities, not only counts, so a repeated page cannot pass. Then add an order between page requests and explain whether the specified cursor or offset behavior permits duplicates or omissions.
Build a compact, meaningful test matrix
Write one row each for valid creation, invalid quantity, unauthorized access, repeated idempotent submission, dependency failure, and pagination boundaries. Each row needs setup, request, expected response, expected state, and cleanup. Keep shared credentials and generated IDs out of source control and logs; use the test environment's approved secret handling.
Practise explaining which cases belong in a quick CI gate and which require a controlled failure environment. Cluegent can help challenge your coverage during preparation, but the service contract determines the assertions. The Postman-specific guide below covers tool-oriented questions; this page focuses on choosing tests that reveal business and reliability defects.
Sources checked
These official references support the guide. Product details and technical documentation can change; check the linked source for current information.
Where Cluegent helps
Cluegent supports permitted live workflows with transcript context, typed prompts, screenshot-aware answers, resume context, custom response behavior, quick action buttons, and a private desktop overlay. It is most useful when you already understand the subject and need help staying structured under pressure.
Frequently asked questions
Is checking HTTP 200 enough?
No. Verify response content, access rules, side effects, and the operation's documented contract. A successful status can accompany an incorrect result.
Can I safely retry every POST request?
No. Safety depends on the endpoint's contract and idempotency behavior. A timeout does not prove that the server failed to perform the operation.