Back to Courses
MANUAL TESTING WITH POSTMAN — FROM ZERO TO JOB-READY

API Manual Testing with Postman

A practical 16-day course covering REST API fundamentals, HTTP methods & status codes, JSON, Postman Collections, Variables, Authentication, Test Assertions, Pre-request Scripts, and Collection Runner — from first principles to a complete working test suite.

15+
Days of Training
13
Modules
100+
Topics Covered
Hands-On
Postman

 Who Is This Course For?

This course is for manual testers, freshers, and anyone who wants to learn API testing using Postman — one of the most in-demand QA skills in the industry today. No programming background needed. You will go from understanding what a REST API is, to sending HTTP requests, validating JSON responses, handling authentication, writing test assertions, and running data-driven test suites using Postman's Collection Runner.

REST & HTTP Fundamentals GET / POST / PUT / PATCH / DELETE Status Codes 2xx / 4xx / 5xx JSON & XML Postman Collections & Environments API Key & Bearer Token Auth pm.test() & pm.expect() Assertions Collection Runner & CSV Data Files

🚀 Course Progression

From "what is an API?" to building and running a complete automated Postman test suite — step by step.

1HTTP & API Basics
2Postman & Auth
3Testing & Scripts
4Automation & Runner
🏆API Tester!
MODULE 01  What is an API?
💡 Why This Module Matters: Before you can test an API, you need to understand what it is and why it exists. This foundation shapes every decision you make as a tester — from what to test, to how to document bugs, to how you explain your work in interviews.
API Concepts & Architecture
  • API (Application Programming Interface) — a contract that lets two software systems exchange data; how apps talk to each other behind the scenes
  • REST (Representational State Transfer) — the most widely used architectural style for web APIs; stateless, resource-based communication
  • HTTP (HyperText Transfer Protocol) — the transport protocol used by every REST API; every request and response travels over HTTP
  • Client-server model — your test tool (Postman) is the client; the API server processes requests and returns responses
  • Monolithic architecture — one large application that handles everything; harder to scale and test independently
  • Microservices — small independent services, each with its own API; testing each service separately is faster and more targeted
  • API Gateway — the front door that receives all requests and routes them to the correct microservice
MODULE 02  HTTP Methods & CRUD Operations
💡 Why This Module Matters: Every single API test you write is based on an HTTP method. Knowing which method to use and what it means is the difference between writing meaningful tests and just clicking Send and hoping for the best.
HTTP Methods Mapped to CRUD
  • GET — Read/retrieve data; no body needed; safe and idempotent — sending it 100 times changes nothing
  • POST — Create a new resource; requires a request body with the data to save; not idempotent
  • PUT — Full update; replaces the entire resource with what you send; whatever you leave out gets removed
  • PATCH — Partial update; only the fields you specify are changed; everything else stays the same
  • DELETE — Remove a resource; typically returns 204 No Content — success with no data back
  • HEAD — Like GET but returns only headers; used for health checks without loading actual data
  • OPTIONS — Returns a list of HTTP methods the server supports for a given endpoint; used in CORS preflight
MODULE 03  HTTP Status Codes
💡 Why This Module Matters: Status codes are the first thing you check in every test result. A tester who can read a three-digit code and instantly know whether the problem is in the request, the server, or the data is worth far more than one who just checks "did I get a response?"
2xx — Success & 3xx — Redirects
  • 200 OK — Request succeeded; result is in the body — typical for GET and PUT
  • 201 Created — New resource created successfully — typical for POST; often includes new resource URL in Location header
  • 202 Accepted — Request accepted for processing but not yet completed (asynchronous operations)
  • 204 No Content — Success but no data returned — typical for DELETE
  • 301 Moved Permanently / 302 Found — Resource has moved; client should follow the new URL
4xx — Client Errors & 5xx — Server Errors
  • 400 Bad Request — Your request has a problem: missing field, wrong format, invalid value — fix the request
  • 401 Unauthorized — Not authenticated; no token, expired token, or wrong credentials
  • 403 Forbidden — Authenticated but not permitted; you're logged in but your role doesn't allow this action
  • 404 Not Found — The resource you asked for doesn't exist; check the ID or URL
  • 500 Internal Server Error — Server-side failure; the bug is in the application code, not your request
  • 502 Bad Gateway / 503 Service Unavailable — Infrastructure issues; server or upstream service is down
MODULE 04  Request & Response Structure
💡 Why This Module Matters: A complete test validates more than just the response body. Headers, status lines, response time, and parameter types all matter — and knowing every part of a request and response means you catch bugs that less thorough testers miss entirely.
Request Anatomy
  • Endpoint — the full URL of a specific resource: https://api.example.com/v1/users/42
  • Path parameter — a variable embedded in the URL path: /users/{id} — identifies a specific record
  • Query parameter — appended after ? for filtering or searching: /products?category=books&limit=10
  • Request Headers — metadata sent with every request: Content-Type: application/json, Authorization: Bearer <token>
  • Request Body / Payload — the data you send to create or update (required for POST, PUT, PATCH)
Response Anatomy
  • Status line — HTTP version + code + phrase: HTTP/1.1 201 Created
  • Response Headers — server metadata: Content-Type, Cache-Control, X-Request-Id
  • Response Body — the data returned: JSON object, array, or empty for 204
  • Response time — how fast the server responded in milliseconds; a performance validation point
MODULE 05  JSON Deep Dive
💡 Why This Module Matters: Almost every modern API sends and receives JSON. If you can't read and write JSON confidently, you can't write meaningful request bodies or validate response data accurately. This module is the difference between surface-level testing and deep, reliable testing.
JSON Structure & Data Types
  • JSON Object — key-value pairs in curly braces: {"id": 1, "name": "Bhanu", "active": true}
  • JSON Array — ordered list in square brackets: ["admin", "viewer", "editor"]; array of objects: [{...},{...}]
  • Data types — String (in double quotes), Number (no quotes), Boolean (true/false), null, nested Object, Array
  • Nested JSON — objects inside objects; the standard structure for real API responses
  • Common JSON mistakes that cause 400 Bad Request — missing commas, single quotes, trailing commas, wrong brackets
  • JSON vs XML — JSON is lighter and easier to read; XML uses tags like HTML; most REST APIs use JSON today
MODULE 06  Getting Started with Postman
💡 Why This Module Matters: Postman is the standard tool for API testing in the industry. Getting comfortable with its interface from day one means you spend your time testing — not fighting the tool. Most QA job descriptions now list Postman as a required skill.
Postman UI & Basic Requests
  • Installing Postman desktop app; signing in; Postman workspace overview
  • Sending a GET request — enter URL, click Send, read the response body, status, and time
  • Sending a POST request — select Body tab → raw → JSON → enter payload → Send
  • Response panel tabs — Body (Pretty / Raw / Preview), Headers, status code, response time, size
  • Saving requests to a Collection — naming, adding to a folder, adding description
  • Request history and duplicating requests for reuse
MODULE 07  Collections, Environments & Variables
💡 Why This Module Matters: No professional tester hardcodes URLs and tokens into every request. Collections keep your work organised and shareable; environments let the same test run against Dev, Staging, or Production with a single switch; variables make your tests dynamic and reusable.
Collections
  • Postman Collection — a named folder of related API requests; the shareable unit of API test work
  • Creating collections, adding folders per module or feature, organising by CRUD operation type
  • Exporting as JSON file for sharing; importing a colleague's collection to run immediately
Environments & Variables
  • Environment — a named set of key-value pairs (Dev, Staging, Production); switch in one click, no request edits needed
  • Environment Variable — scoped to the selected environment: {{base_url}}, {{token}}
  • Collection Variable — scoped to the collection; shared across all requests within it
  • Global Variable — available everywhere in Postman across all collections and environments
  • Variable syntax in requests — {{variable_name}} in URL, header value, or body
  • Setting variables from a response: pm.environment.set("userId", pm.response.json().id)
MODULE 08  Authentication & Authorization
💡 Why This Module Matters: Most real-world APIs are secured. If you can't handle authentication in Postman, you can't test 80% of a real application. Understanding auth also helps you write better security-related negative test cases — which is something every interviewer asks about.
Authentication Types
  • Authentication vs Authorization — Authentication = who you are; Authorization = what you are allowed to do
  • API Key — a static key sent as a header: x-api-key: abc123 or as a query parameter
  • Bearer Token — sent in the Authorization header: Authorization: Bearer <jwt_token>
  • Basic Auth — username and password encoded as Base64 in the Authorization header
  • OAuth 2.0 — a flow where you get a temporary access token from an auth server and use it to call protected APIs
  • JWT (JSON Web Token) — a self-contained token with three sections: Header, Payload (claims), Signature
Handling Tokens in Postman
  • Storing the token in an environment variable {{access_token}} — never hardcode tokens in requests
  • Login flow: POST /login → extract token from response body → pm.environment.set("token", ...)
  • Token expiry — causes 401 Unauthorized; test for this scenario specifically
  • Setting Auth at the collection level so all requests inherit it automatically
MODULE 09  Positive & Negative Testing
💡 Why This Module Matters: A tester who only checks the happy path misses half the bugs. APIs fail in predictable ways — bad input, missing auth, wrong permissions, non-existent resources. Testing these "expected failure" scenarios is what makes a QA engineer genuinely valuable to a team.
Positive Test Scenarios — Happy Path
  • Valid GET with existing resource ID → expect 200 OK + correct data in body
  • Valid POST with all required fields → expect 201 Created + new resource in response
  • Valid PUT/PATCH with correct ID and body → expect 200 OK + updated data
  • Valid DELETE with existing resource ID → expect 204 No Content
Negative Test Scenarios — Error Path
  • Missing required field in POST body → expect 400 Bad Request with meaningful error message
  • Wrong data type (e.g. text where a number is expected) → expect 400 Bad Request
  • GET with a non-existent ID → expect 404 Not Found
  • No token in the request header → expect 401 Unauthorized
  • Valid token but accessing a resource the user has no permission for → expect 403 Forbidden
  • Boundary values — maximum field length, minimum numeric value, empty string, zero
  • Duplicate POST — creating a resource that already exists → expect 400 or 409 Conflict
MODULE 10  Test Scripts & Assertions
💡 Why This Module Matters: Manual checking — reading the response and deciding if it's right — doesn't scale. Test scripts run automatically after every request and give you a pass/fail result instantly. This is what separates a manual tester from a semi-automated API tester, and it's a skill employers specifically look for.
Writing Tests in Postman
  • The Tests tab — JavaScript that Postman runs automatically after every response is received
  • pm.test("description", function() { ... }) — structure of every Postman test case
  • pm.response.to.have.status(201) — assert the exact status code returned
  • pm.response.to.have.header("Content-Type") — assert a specific header is present
  • pm.response.responseTime < 2000 — assert response is under 2 seconds
Response Body Assertions
  • const json = pm.response.json() — parse response body as a JavaScript object
  • pm.expect(json.name).to.eql("Bhanu") — assert exact field value
  • pm.expect(json).to.have.property("id") — assert a key exists in the response
  • pm.expect(json.id).to.be.a("number") — assert correct data type
  • pm.expect(json.items).to.be.an("array").that.is.not.empty — assert non-empty array
  • Chaining: .to.include, .to.not.be.null, .to.be.true, .to.be.above(0)
MODULE 11  Pre-request Scripts
💡 Why This Module Matters: Real test scenarios require setup — unique data, fresh tokens, IDs from previous responses. Pre-request scripts automate this setup so your test suite is self-sufficient and repeatable. Without this skill, you end up manually copying values between requests, which defeats the purpose of automation.
Dynamic Data & Request Chaining
  • Pre-request Script — JavaScript that runs BEFORE the request is sent; perfect for generating dynamic test data
  • Generating unique values: pm.environment.set("email", "user" + Date.now() + "@test.com")
  • Conditional token refresh — check if token exists, only call POST /login when it doesn't
  • Request chaining — POST /users creates user → extract id → store as {{userId}} → use in GET /users/{{userId}}
  • Full workflow automation: Login → extract token → create record → retrieve it → update → delete — all chained automatically
MODULE 12  Collection Runner & Data-Driven Testing
💡 Why This Module Matters: Running one request at a time isn't testing — it's clicking. Collection Runner lets you run your entire test suite in one go and see a complete pass/fail summary. Pairing it with a CSV data file means you can test 50 different inputs without writing 50 separate requests.
Collection Runner
  • Collection Runner — executes all requests in a collection sequentially in one automated run
  • Configuring iterations — how many times the entire collection runs; delay between requests in milliseconds
  • Selecting specific requests or folders to include in the run
  • Results panel — per-request pass/fail summary, assertion details, response time
  • Exporting run results as HTML or JSON report to share with the team
Data-Driven Testing with CSV
  • CSV data file — each row is one test iteration; column headers become variable names in Postman
  • Uploading CSV in Runner — select file, Postman automatically creates one iteration per row
  • Using {{column_name}} in URL, body, and headers — same request runs with different data each time
  • Example: test POST /users with 20 different name/email combinations from a single CSV — no code needed
  • JSON data file as alternative for complex nested test data structures
MODULE 13  End-to-End API Test Strategy
💡 Why This Module Matters: Knowing Postman is a tool skill. Having a test strategy is a professional skill. Companies hire testers who can look at API documentation, build a complete test plan, organise their work, and plug it into a delivery pipeline — not just testers who know how to click Send.
Swagger / OpenAPI & Test Planning
  • Swagger / OpenAPI — the industry-standard format for documenting REST APIs; your primary source for test cases
  • Reading Swagger UI — endpoints, request/response schemas, required fields, example payloads
  • Importing OpenAPI spec into Postman — auto-generates a collection with all endpoints ready to test
  • Deriving test cases from documentation — positive cases, negative cases, boundary values, security tests
Test Organisation & CI/CD
  • Collection folder structure — organise by feature: Login folder, Users folder, Products folder, Orders folder
  • Happy Path folder + Error Scenarios folder within each feature — clear separation of test types
  • Environment strategy — separate Dev, QA, Staging, and Production environments for safe multi-environment testing
  • Regression suite — a curated collection of critical tests re-run after every release to catch regressions
  • Newman — Postman's command-line runner: newman run collection.json -e environment.json
  • CI/CD integration — trigger Newman automatically via Jenkins, GitHub Actions, or any pipeline after each deployment
Interview Preparation

GET vs POST — GET retrieves with no body; POST creates with a body; GET is idempotent (safe to repeat), POST is not

401 vs 403 — 401 = not authenticated (missing or invalid token); 403 = authenticated but not authorised (wrong role or permission)

PUT vs PATCH — PUT replaces the whole resource; PATCH updates only the fields you specify

What do you validate? — Status code, response body fields and types, required keys present, response time, Content-Type header

Bearer Token flow — POST /login → pm.environment.set("token", json.token) → Authorization: Bearer {{token}} on all protected requests

Data-driven testing — Upload CSV to Collection Runner; each row runs as a separate iteration; {{column}} variables pull in each row's data automatically