Junior testers jump straight into writing tests. Senior testers write a test plan first. The difference? Juniors miss 40% of scenarios. Seniors cover everything because they planned before coding.
A test plan for API testing is not a 50-page document. It is a focused list of what to test, how to test it, and what "pass" looks like. Let us build one.
Before writing a single test, list every endpoint you need to cover. Here is what we are working with.
| API | Endpoint | Method | Description |
|---|---|---|---|
| JSONPlaceholder | /posts | GET | Get all posts (100 items) |
| JSONPlaceholder | /posts/{id} | GET | Get single post by ID |
| JSONPlaceholder | /posts?userId={id} | GET | Filter posts by user |
| JSONPlaceholder | /posts | POST | Create a new post |
| JSONPlaceholder | /posts/{id} | PUT | Update entire post |
| JSONPlaceholder | /posts/{id} | PATCH | Partial update |
| JSONPlaceholder | /posts/{id} | DELETE | Delete a post |
| JSONPlaceholder | /posts/{id}/comments | GET | Comments for a post |
| JSONPlaceholder | /users | GET | Get all users (10 items) |
| JSONPlaceholder | /users/{id} | GET | Get single user |
| ReqRes.in | /api/users?page={n} | GET | Users with pagination |
| ReqRes.in | /api/users/{id} | GET | Single user |
| ReqRes.in | /api/users | POST | Create user |
| ReqRes.in | /api/users/{id} | PUT | Update user |
| ReqRes.in | /api/users/{id} | DELETE | Delete user |
| ReqRes.in | /api/register | POST | Register (needs email + password) |
| ReqRes.in | /api/login | POST | Login (needs email + password) |
| ReqRes.in | /api/users?delay=3 | GET | Delayed response (3 seconds) |
Every endpoint needs tests in at least three categories. Most people only write positive tests and call it a day. That is how bugs slip into production.
Here is a lightweight test plan format. Copy this for every API project you work on.
# API Test Plan — Capstone Project
## Scope
- APIs under test: JSONPlaceholder, ReqRes.in
- Test types: Functional, Schema, Negative, Data-driven
- Tools: Postman/Newman (ReqRes.in), REST Assured (JSONPlaceholder)
## Test Categories
### Positive Tests
- GET all resources — verify count, structure, status 200
- GET single resource — verify all fields, correct ID
- POST new resource — verify 201, returned data matches input
- PUT update — verify 200, updated fields reflected
- PATCH partial update — verify only specified fields change
- DELETE — verify 200/204
- Filtering — verify query params return correct subset
- Pagination — verify page size, total count, navigation
- Nested resources — verify /posts/{id}/comments relationship
### Negative Tests
- GET non-existent ID (99999) — verify 404
- POST with missing required fields — verify 400
- POST with wrong data types — verify 400
- PUT non-existent resource — verify 404
- Login with wrong password — verify 400
- Register without password — verify 400
### Edge Case Tests
- GET with ID = 0 — verify behavior
- GET with negative ID — verify behavior
- GET with string ID — verify behavior
- POST with empty body — verify behavior
- POST with extra unknown fields — verify behavior
- Very long string values (1000+ chars)
### Schema Validation
- Post response matches post-schema.json
- User response matches user-schema.json
- Comment response matches comment-schema.json
- Error response matches error-schema.json
### Performance Checks
- Response time < 2 seconds for all endpoints
- Delayed response endpoint returns after expected delay
## Entry Criteria
- APIs are accessible and returning expected data
- Test tools installed (Postman, Newman, Java 17, Maven)
## Exit Criteria
- All planned tests executed
- Pass rate > 95%
- All schema validations pass
- HTML reports generatedKeep this test plan in your project root as test-plan.md. When you show this project in an interview, the test plan shows you think before you code. That separates senior from junior.
Q: How do you plan your API test coverage?
A: I start by listing every endpoint from the API documentation or Swagger spec. For each endpoint, I identify three test categories — positive (happy path with valid data), negative (invalid inputs, missing fields, unauthorized), and edge cases (boundary values, empty strings, special characters). I also add schema validation tests for every resource type to catch contract changes. I document this in a lightweight test plan with scope, categories, entry criteria, and exit criteria. The plan typically identifies 3-5x more tests than what most people think of. I review the plan with the team before writing code to catch blind spots early.
Key Point: Plan before you code. List all endpoints, define three test categories (positive, negative, edge), and document your plan. A good test plan catches 40% more scenarios than ad-hoc testing.