Postman helps QA explore APIs and turn a successful manual request into a repeatable check. Its value begins with explaining which contract was violated, what data was sent, and why the response is unacceptable to the user. Clicking Send and seeing 200 is insufficient: the server may return someone else's order, the wrong currency, or a success response without saving data. Organize your work around scenarios and testable expectations.
What a working collection contains
A request specifies a method, URL, headers, authorization, and body. A collection groups related requests and shared settings, while a folder can represent a user journey. An environment supplies parameters for a particular deployment. Pre-request scripts prepare data, and post-response scripts verify results. Responses and request history help investigations but do not replace a saved scenario: colleagues should be able to reproduce the check without your local state or verbal explanations.
Starting an API investigation
First find the behavioral agreement: OpenAPI, requirements, client examples, and role restrictions. Verify the environment URL and service version, then send the smallest valid request. Remove optional fields and determine which ones actually affect the result. Save a working example with a purpose description. Then change one condition at a time: a field type, a missing required value, user permissions, or object state. This turns observation into a controlled experiment.
Variables without hidden dependencies
Store the service address in baseUrl and the created order's identifier in orderId. {{baseUrl}}/orders/{{orderId}} is clearer than an arbitrary address with a hardcoded number. In Postman, variable values depend on scope: global, collection, environment, iteration data, and local. Reusing a name across scopes complicates debugging. Before running tests, check the selected environment and resolved address value; do not rely solely on the tab name.
Store tokens and passwords in a mechanism designed for secrets, and supply CI secrets through the runtime environment. Before exporting, inspect variable values and response examples separately. Marking a value as sensitive and masking it in the interface do not prove that it is absent from files, the console, or attached reports.
Practice: creating and reading an order
Suppose the test API contract creates orders through POST /orders and returns 201, id, and totalMinor in minor currency units. You have user buyer-a, a test product, and real charging disabled. For this example, one product costs 1250, quantity is two, and delivery is free. These are the test inputs and expected outcome, rather than a universal API format.
- 1.Create an order with quantity=2. Expect 201, a nonempty identifier, and totalMinor=2500; save id only after validating the response.
- 2.Call GET /orders/{{orderId}} as the same user. Expect the same owner, contents, and total; confirm successful creation by reading the order.
- 3.Repeat the read as buyer-b. Expect the contract-defined rejection without another user's order contents; the specific code depends on service policy.
- 4.Send quantity=0. Expect the agreed validation error and no new order; verify the side effect through an available method.
Checks that establish meaningful results
A post-response script should verify business values and structure alongside the HTTP code. For example, a creation request can use the following assertions. Saving id conditionally protects the next step from obviously invalid data, but does not make the entire chain independent of state.
pm.test('Order created', () => {
pm.response.to.have.status(201);
const body = pm.response.json();
pm.expect(body.id).to.be.a('string').and.not.empty;
pm.expect(body.totalMinor).to.eql(2500);
});
if (pm.response.code === 201) {
const body = pm.response.json();
if (typeof body.id === 'string' && body.id.length > 0) {
pm.environment.set('orderId', body.id);
}
}Avoid comparing an entire response with a single hardcoded snapshot when it contains creation times and random identifiers. Check required fields, types, and valid relationships between values. Assess unexpected additional attributes against the compatibility contract instead of automatically reporting a defect.
Repeatable runs and data cleanup
The collection should create its own data or explicitly document setup. Clear old orderId values before repeating the run to avoid reading a previous run's order. Explain how test entities are deleted or marked and how to recover after a partial failure. Use a unique run marker for concurrent runs. A shared user and permanent order often turn valid checks into random races between testers.
Running in CI
As of October 2026, Postman v12 documentation describes collection format v3 and recommends Postman CLI. Newman is deprecated, no longer supported, and cannot execute v3. First establish the collection format, available scripts, and selected runner. Always trial a request's migration from the application to CI: local vaults, cookies, and interface capabilities should not be assumed available in another environment.
For asynchronous operations, a successful response may mean only that a job was accepted. If creation returns a processing status, define how to wait for the final state, the maximum wait, and acceptable intermediate responses. Avoid substituting an arbitrary long pause: a fast environment wastes time, while a slow one remains unstable. Separately check retrying after a timeout: an outcome unknown to the client does not mean no object was created. If idempotency keys are supported, preserve the key across retries of the same intent and verify that no second order appears.
Investigating discrepancies
Compare the actual URL, authorization, headers, and body sent, followed by the status, response, and timing. Check variable resolution and automatic redirects. A successful manual run with a failing CI run often involves a different token, time zone, missing data, or networking. Attach a minimal anonymized request, contract expectation, actual response, build, and correlation ID to the defect. A full environment dump usually contains more unnecessary data than useful evidence.
Common mistakes and QA outcomes
Common mistakes include keeping an entire regression suite in unsaved tabs, treating a green status as proof of correctness, manually changing addresses in dozens of requests, and running state-changing operations in the wrong environment. Another is an uncontrolled chain where the first failure creates twenty secondary errors. A good collection has clear setup, meaningful checks, diagnosable dependencies, and safe cleanup. Postman then supports API discussions based on reproducible facts.
Further reading
A repeatable local collection: status, schema and business state
Use a fictional API with GET /items and POST /items. Its stated contract accepts a nonempty name and integer quantity from 1 through 10; a valid write returns 201, an out-of-range quantity returns 422, and malformed JSON returns 400. These statuses belong to this example, not every API. Start from one prepared item and reset the disposable fixture before every collection run.
Run order Request Expected result
1 Reset the disposable fixture One initial item
2 GET /items 200; items is an array of length 1
3 POST /items {"name":"Pen","quantity":2} 201; id=2, name=Pen, quantity=2
4 POST /items {"name":"Pen","quantity":11} 422; quantity-range error
5 POST /items with malformed JSON 400; invalid-json error
6 GET /items Exactly 2 items; rejected writes added nothingA status assertion alone can miss a wrong business result. Add a schema assertion for required fields and types, then compare the important values. A final read checks persistence and absence of side effects. Keep baseUrl in a separate environment; never put a real credential into the exported teaching collection.
pm.test('Created', () => pm.response.to.have.status(201));
pm.test('Business values', () => {
const item = pm.response.json();
pm.expect(item.name).to.eql('Pen');
pm.expect(item.quantity).to.eql(2);
});For new automation, consult the current Postman CLI workflow. The official Postman guidance now recommends its maintained CLI; Newman is a compatibility option for existing v2.1 collections. For an exported local v2.1 collection, a compatibility command is newman run collection.json -e environment.json. Bind the teaching server to loopback and reset its disposable fixture before the run.