Before you test any API, you need to know what it does. That information lives in the API documentation. Good docs tell you every endpoint, every parameter, every possible response. Bad docs... well, bad docs are why testers have gray hair.
The most common format is Swagger (now called OpenAPI). You'll see it in almost every company. It's an interactive web page where you can read the docs AND test the APIs right there.
Base URL — the root address. Example: https://api.banking.com/v1
Endpoints — the specific paths. Example: /accounts, /transactions, /transfer
HTTP Method — GET, POST, PUT, DELETE for each endpoint
Request Parameters — path params, query params, headers, body schema
Request Body Schema — exact JSON structure with field names, types, required/optional
Response Schema — what the response looks like, field names, types
Status Codes — what each code means for this specific endpoint
Authentication — how to pass your token (Bearer token, API key, etc.)
Rate Limits — how many calls per minute/hour you're allowed
Example requests and responses — copy-paste ready samples
# This is what you'll see in Swagger/OpenAPI docs
/api/banking/transfer:
post:
summary: Transfer funds between accounts
security:
- bearerAuth: [] # Needs login token
requestBody:
required: true
content:
application/json:
schema:
type: object
required: [from, to, amount] # These 3 fields are mandatory
properties:
from:
type: string
example: "ACC-001"
to:
type: string
example: "ACC-002"
amount:
type: number
minimum: 1 # Must be at least 1
example: 5000
note:
type: string # Optional field
example: "Rent payment"
responses:
201:
description: Transfer successful
400:
description: Missing required fields
401:
description: Not authenticated
422:
description: Insufficient fundsFrom this ONE entry, you can extract at least 10 test cases. Let me show you.
Key Point: API documentation is your test plan blueprint. Every field, every constraint, every status code is a test case waiting to be written. Read the docs before writing a single test.
If the docs say a field is required — test without it. If it says minimum value is 1 — test with 0 and -1. If it says a field is a string — send a number. Every constraint in the docs is an invitation to write a negative test case.
Swagger docs can be outdated. Developers change the API but forget to update the docs. Always verify with actual calls. If the docs say "returns 201" but the API returns 200, file a bug — either the API or the docs are wrong.
Q: How do you create test cases from API documentation?
A: I start by reading the Swagger/OpenAPI docs for each endpoint. For every required field, I write a test without it (negative case). For every optional field, I test with and without it. I check boundary values — minimum, maximum, empty strings, null. I verify all documented status codes actually match the API's behavior. I also test authentication — no token, expired token, wrong role. One well-documented endpoint typically gives me 10-15 test cases.
Key Point: Swagger/OpenAPI docs are your test plan. Every constraint is a test case. Read them thoroughly before touching Postman.