Interview Corner

A: Postman has five variable types in order of precedence: 1) Data variables — from CSV/JSON files during Collection Runner, highest priority. 2) Local variables — set via pm.variables.set() in scripts, live only during execution. 3) Environment variables — tied to the active environment (dev/staging/prod), most commonly used. 4) Collection variables — stored in the collection file, same value regardless of environment. 5) Global variables — available across all collections, broadest scope. When multiple scopes have the same variable name, the narrower scope wins.

A: Data-driven testing in Postman uses the Collection Runner with an external data file (CSV or JSON). Each row/object in the file represents one test iteration. Column headers become data variables accessible via {{columnName}} in requests and pm.iterationData.get("columnName") in scripts. Steps: 1) Create the data file with test inputs and expected outputs. 2) Set up the request using data variables. 3) Write assertions that compare actual responses to expected values from the data file. 4) Open Collection Runner, select the data file, set iteration count, and run. This lets you test 100 scenarios with a single request definition.

A: Three approaches: 1) Pre-request script approach — add a pre-request script at the collection level that checks if the token is expired (compare stored expiry timestamp with current time) and calls the login endpoint to refresh it before each request. 2) Chaining approach — place a Login request as the first request in the collection, extract the token in its post-response script, and save it to an environment variable. All subsequent requests use {{authToken}}. 3) For OAuth2, use Postman's built-in authorization tab which handles token refresh automatically. The pre-request script approach is the most robust for CI/CD because it handles mid-run expiration.

A: postman.setNextRequest("requestName") controls the execution order in Collection Runner. By default, requests run sequentially. setNextRequest lets you jump to a specific request, skip requests, or create loops. Use cases: 1) Conditional branching — if login fails, retry; if it succeeds, proceed. 2) Skipping cleanup if create failed. 3) Looping — retry a request until a condition is met (polling). 4) Stopping the run early with setNextRequest(null). Important: it only works in Collection Runner, not manual sends, and request names are case-sensitive.

A: Use collection variables for non-sensitive defaults (apiVersion, content type) — these export with the collection. Use environment variables with Current Value (not Initial Value) for secrets — Current Values stay local and are not synced to Postman cloud. Set variable type to "secret" to mask values in the UI. When sharing: 1) Export the collection (includes collection variables, not environment variables). 2) Share a template environment with placeholder values like "your-token-here." 3) Document which variables teammates need to fill in. 4) Never commit .postman_environment.json files to git. 5) Use Postman workspaces for team collaboration with role-based access.

A: pm.environment.set() saves the variable to the currently active environment — it is tied to that specific environment (e.g., Dev or Staging). When you switch environments, the variable only exists in the one where you set it. pm.globals.set() saves the variable globally — it is available across ALL collections and ALL environments in your Postman workspace. Use environment variables for server-specific values (URLs, tokens). Use globals sparingly — only for truly universal values like a shared API key used across multiple projects. Over-using globals leads to name collisions and confusion.

A: Use data-driven testing with a CSV or JSON file containing all 500 test cases. Each row includes input fields (name, email, password, etc.) and expected outcomes (status code, error message, etc.). Create a single POST request to the registration endpoint with {{variables}} for all inputs. Write post-response assertions that compare actual response to expected values from the data file. Run it via Collection Runner with 500 iterations. For CI/CD integration, export the collection and run it via Newman CLI with the data file: newman run collection.json -d testdata.csv -e environment.json. This runs all 500 test cases in minutes without manual intervention.