Postman and manual API testing

Postman is a desktop and web tool for sending API requests by hand, saving them, and adding small checks. It is the tool most interviewers expect you to know for manual API testing and for exploring an API by hand, and the questions are practical: how you organize requests, switch servers, pass a token from one request to the next, write checks, and run the same requests in CI (continuous integration, a server that runs your tests automatically, for example after every code change; see the CI/CD stage). This article covers each.

Requests and collections

A request in Postman has a method, a URL, parameters, headers, authorization settings and a body. A collection is a saved group of requests, usually with a folder per feature (Auth, Products, Orders). Collections also hold scripts and authorization settings that every request inside can inherit, so you set "Bearer Token" once on the collection instead of on fifty requests.

Environments and variables

Instead of typing https://staging.example.com in every request, write {{baseUrl}}/orders. An environment is a named set of variables, one per server: Local, Test, Staging. Switching the environment points every request at another server.

Postman has several variable scopes. From broadest to narrowest they are global, collection, environment, data (from a data file during a run) and local (set by a script for one run). When the same name exists in several scopes, the narrowest one wins. A forgotten global or local value is a common reason a request goes to the wrong place; the Postman Console (a log window) shows the final URL that was really sent, with every variable already replaced by its value.

Each variable has a value that syncs to the team (shared, called initial value in older versions) and a value that stays on your machine (local, formerly current value). Real passwords and tokens must never be in the shared value, because shared workspaces and exports carry it. Keep them in local values or Postman Vault (Postman's protected storage for secrets), and pass them from the CI secret store (the safe place where the CI tool keeps passwords) in pipelines.

Scripts and tests

Postman runs JavaScript before a request (the pre-request script) and after the response (the post-response script, shown as Tests in older versions). You do not need to know JavaScript well: the examples below can be copied and changed. The pm object gives access to the request, the response and the variables:

pm.test("status is 201", function () {
    pm.response.to.have.status(201);
});

const body = pm.response.json();
pm.test("email is saved", function () {
    pm.expect(body.email).to.eql(pm.variables.get("email"));
});

pm.test("answers within 2 seconds", function () {
    pm.expect(pm.response.responseTime).to.be.below(2000);
});

Each pm.test becomes one named result. Keep one idea per test, so a failure says exactly what broke. A pre-request script prepares data, for example a unique email per run:

pm.variables.set("email", "user" + Date.now() + "@example.com");

Postman also has built-in dynamic variables such as {{$guid}} and {{$timestamp}}.

Chaining requests: the token example

The login request's post-response script saves the token:

pm.collectionVariables.set("token", pm.response.json().token);

The collection's authorization is set to Bearer Token with {{token}}, so every later request sends Authorization: Bearer .... The login request must run first. The same pattern passes ids: create an order, save its id, then GET, PATCH and DELETE it.

Data files and the Collection Runner

The Collection Runner runs a collection or folder in order and shows every test result. With a CSV file (a plain text table, one row per line, values separated by commas) or a JSON data file, it runs once per row: column names become variables, so the body can use {{email}} and a test can read pm.iterationData.get("expectedStatus"). This suits validation rules with many inputs; when rows need different steps or checks, separate requests are clearer.

Newman: Postman in CI

Newman is the command-line runner for collections, so it can run without the Postman window. It is installed with npm, the package tool of Node.js (a program that runs JavaScript outside the browser):

npm install -g newman
newman run shop.postman_collection.json \
  -e staging.postman_environment.json \
  -d signup-data.csv \
  -r cli,junit --reporter-junit-export results/newman.xml

-e picks the environment file, -d a data file, -r the reporters, and --reporter-junit-export where the JUnit XML goes (JUnit XML is a common file format for test results that CI tools can read). Newman ends with exit code 1 (a number a program returns when it finishes; 0 means success) when any assertion fails, so the CI step fails on its own, and the JUnit file shows results per test in Jenkins or GitHub Actions.

How to answer in an interview

Describe your setup as a structure: collections with a folder per feature, one environment per server, the token chained from the login request, pm.test checks on status and key fields, a data file for validation rules, and Newman in CI with a JUnit report. Then name a limit: when a collection grows large with complex logic, you move the stable checks into code (REST Assured or pytest) and keep Postman for exploration.

Common mistakes

• Copying the token into every request by hand, so everything breaks when it expires.
• Keeping real passwords in shared values or exported files.
• Not knowing which scope a variable came from when a request goes to the wrong server.
• Writing one huge pm.test with many checks, so a failure does not say what broke.

Recap

Collections hold requests, environments hold per-server values, and the narrowest variable scope wins. Scripts prepare data before a request and check the response after it; chaining passes tokens and ids along. Newman runs the same collection in CI and fails the step when a check fails. In daily work, read the resolved request when something looks wrong, and attach the request and response to every bug report.