These are the Postman-specific questions that come up in QA interviews. Most candidates can say "I used Postman." The ones who get hired can explain HOW they used it — collections, variables, environments, auth, assertions. That's what we're covering here.
Q: What is Postman and why do you prefer it for API testing?
A: Postman is an API development platform that I use for manual and semi-automated API testing. I prefer it because it saves requests in collections (reusable test suites), supports environment variables (switch between dev/staging/prod in one click), lets me write test assertions in JavaScript, and makes sharing easy via workspace sync or JSON export. For quick exploration and manual testing, nothing is faster.
Q: How do you organize your API tests in Postman?
A: I create one collection per service or module — like "User Service" or "Payment API." Inside each collection, I use folders grouped by resource (Users, Orders, Payments) or by test type (Smoke, Regression, Negative). Each request has a descriptive name like "Create User — Valid Data" or "Get Order — Invalid ID (404)." I set auth and base URL at the collection level so individual requests stay clean.
Q: What is the difference between path parameters and query parameters?
A: Path parameters are part of the URL path and identify a specific resource — like /users/42 where 42 is the user ID. In Postman, I use /users/:id and fill the value in the Path Variables section. Query parameters come after ? and are used for filtering or pagination — like /users?role=admin&page=2. I manage them in the Params tab where I can toggle them on/off with checkboxes.
Q: How do you handle authentication in Postman?
A: I set auth at the collection level. For Bearer token auth, I first call the login API, extract the token from the response, and store it in a collection variable. Then I set Authorization type to "Bearer Token" with value {{token}} on the collection. Every request inherits it. When the token expires, I re-run the login request — a pre-request script can automate this.
Q: What are Postman environments and how do you use them?
A: Environments are sets of variables that change based on where you're testing. I create separate environments for dev, staging, and production — each with its own baseUrl, token, and test data. In my requests, I use {{baseUrl}}/users instead of hardcoded URLs. Switching from dev to staging is just selecting a different environment from the dropdown. The requests stay the same.
Q: How do you share Postman collections with your team?
A: Two approaches. For live collaboration, I use shared workspaces — everyone on the team sees the same collections, and changes sync in real-time. For CI/CD and version control, I export collections as JSON v2.1 and commit them to our Git repository. We also import Swagger/OpenAPI specs to auto-generate collections when new endpoints are added. Environments are stored separately with placeholder values — real credentials are never committed.
Q: Can you run Postman collections from the command line?
A: Yes, using Newman — Postman's CLI companion. You install it via npm (npm install -g newman), then run: newman run collection.json -e environment.json. It executes every request in the collection, runs test assertions, and gives you a pass/fail report. We integrate Newman into our Jenkins/GitHub Actions pipeline so API tests run automatically on every PR merge.
Q: What do you verify in an API response using Postman?
A: Six things: status code (is it the expected code?), response body (correct data, all required fields, correct data types), no data leakage (passwords or tokens not exposed), response headers (Content-Type, security headers), cookies (HttpOnly and Secure flags on auth cookies), and response time (within SLA — typically under 2 seconds). Most testers only check status code. Thorough testers check all six.
Q: You need to test a new API with 30 endpoints. How do you approach it?
A: First, I import the Swagger spec into Postman — that auto-creates a collection with all 30 endpoints. Then I set up environments for dev and staging with base URLs. I start with happy path tests for each endpoint — correct inputs, expected responses. Then I add negative tests — missing fields, wrong data types, unauthorized access. I organize by resource in folders, set collection-level auth, and use variables for reusable data. Finally, I add test scripts for assertions and run the full collection to verify.
Q: A POST endpoint returns 200 instead of 201 for successful creation. Is that a bug?
A: Technically it works, but it violates REST conventions. 201 Created is the correct status code for resource creation. It tells the client explicitly that a new resource was created. I would file it as a minor bug or improvement suggestion, depending on the team's standards. If the API documentation says 201 but the actual response is 200, that's definitely a defect — either the code or the docs need to be corrected.
Key Point: Interviewers want to hear specifics — collection structure, variable usage, auth handling, team sharing. "I used Postman to send requests" is not enough. Describe your workflow.
Key Point: Go beyond "I used Postman." Explain your collection structure, variable strategy, auth setup, and sharing workflow. Specifics win interviews.
Answer all 5 questions, then submit to see your score.
1. What status code should a POST endpoint return when a resource is successfully created?
2. In Postman, what is the correct syntax for using a path variable in a URL?
3. You send a PATCH request with only { "email": "new@test.com" } to update a user who has name, phone, and email fields. What happens to the name and phone fields?
4. Where should you set the Authorization token in Postman to avoid configuring it on every individual request?
5. When importing a Swagger/OpenAPI specification into Postman, what does Postman automatically generate?