LESSON 01 · FOUNDATIONS
What is an API — and why should you test it?
An API (Application Programming Interface) is a contract between two systems. It defines what requests you can make, what data to send, and what response to expect.
Think of it like ordering at a restaurant. You (the client) tell the waiter (the API) what you want. The waiter goes to the kitchen (the server) and comes back with your food (the response). You never see the kitchen — you just interact with the waiter.
REST APIs are the most common type in modern apps. They use HTTP and return data in JSON format.
As a QA detective, your job is to verify the contract holds — even when someone tries to break it.
Think of it like ordering at a restaurant. You (the client) tell the waiter (the API) what you want. The waiter goes to the kitchen (the server) and comes back with your food (the response). You never see the kitchen — you just interact with the waiter.
REST APIs are the most common type in modern apps. They use HTTP and return data in JSON format.
As a QA detective, your job is to verify the contract holds — even when someone tries to break it.
Q — QA DETECTIVE
"The UI is merely a disguise, Watson. The API is where the real crime happens. Any bug in the backend surfaces through the API — with or without a pretty interface to hide it. Test the waiter, not just the menu."
HTTP REQUEST
GET https://api.qalingo.com/users/42
Authorization: Bearer eyJhbGci...
Content-Type: application/jsonJSON RESPONSE
{
"id": 42,
"name": "Omar A.",
"role": "QA Specialist",
"certified": true,
"xp": 2840
}QUICK CHECK
Section 1
A dev tells you: "Just test the UI — the API is the backend team's problem." What do you say?
Think about where bugs really originate.
Q — QA DETECTIVE
LESSON 02 · HTTP METHODS
The 5 HTTP methods every QA must know
HTTP methods define the action being performed on a resource — they're the verbs of the API language. Each has a specific purpose and creates different test scenarios.
GET
Read / Retrieve
Fetches data without modifying it. Should be idempotent — 10 calls, same result. Test: does it return the right data? Handle non-existent IDs gracefully?
POST
Create
Creates a new resource. Each call typically creates a new record. Test: does it return 201 Created? What happens with duplicate data or missing required fields?
PUT
Replace (full update)
Replaces the entire resource. Omitting a field may delete it. Test: does it correctly overwrite all fields? What if the resource doesn't exist?
PATCH
Partial update
Updates only the fields provided. Other fields remain unchanged. Test: does it only change what you sent? Does it accept or reject unknown fields?
DELETE
Remove
Deletes a resource. Test: does calling DELETE twice return 404 on the second call? Are there cascade effects? Is authorization required?
Q — QA DETECTIVE
"Rookie mistake: assuming GET is harmless. I've seen GET endpoints that triggered background jobs, updated view counters, and leaked sensitive data in response headers. Every method deserves your suspicion."
QUICK CHECK
Section 2
A user updates only their profile picture. The endpoint changes ONLY that field and leaves the rest intact. Which HTTP method is being used correctly?
Full replacement vs partial update — know the difference.
Q — QA DETECTIVE
LESSON 03 · STATUS CODES
HTTP status codes — the API's confessional
Status codes tell you what happened after your request. A good QA knows not just what they mean — but when the wrong code is a bug even if the data looks correct.
2xx
Success200 OK · 201 Created · 204 No Content. The request worked. 204 means success with no body — common for DELETE.
3xx
Redirection301 Moved · 304 Not Modified. Client must take action. Often invisible in browsers but visible in API logs.
4xx
Client errors400 Bad Request · 401 Unauthorized · 403 Forbidden · 404 Not Found · 422 Unprocessable · 429 Too Many Requests.
5xx
Server errors500 Internal Error · 502 Bad Gateway · 503 Unavailable. The server failed. Always a bug. Never acceptable in production.
COMMON BUGS
// ❌ Deleting non-existent resource returns 200
DELETE /users/9999 → 200 OK // Should be 404
// ❌ Missing auth returns 500 instead of 401
GET /admin/reports → 500 Error // Should be 401
// ❌ Invalid email returns 500 instead of 400/422
POST /users { email: "notanemail" } → 500 Error
// ✅ CORRECT: Duplicate returns 409 Conflict
POST /users { email: "user@example.com" } → 409 ConflictQ — QA DETECTIVE
"A 200 OK is not a pass. Watson, I've seen APIs return 200 with an error message inside the body. The status code and the body must tell the same story. When they don't — that's your bug."
QUICK CHECK
Section 3
You send POST to create a user with missing required field "email". The API returns 200 OK with body: {"error": "email required"}. Is this a bug?
What should the status code be when the client sends bad data?
Q — QA DETECTIVE
LESSON 04 · TEST STRATEGY
The QA API Testing Checklist
For every API endpoint, a QA detective runs through these categories. Miss one and the bug will find you — or worse, an attacker will.
✅ Functional Testing
Does it do what it's supposed to do?
• Valid inputs → expected response + correct status
• Business rules applied (e.g. user can't order more than stock)
• Response body has all required fields with correct data types
• Valid inputs → expected response + correct status
• Business rules applied (e.g. user can't order more than stock)
• Response body has all required fields with correct data types
🔒 Security Testing
Can it be exploited?
• Missing auth token → 401 (not 200 or 500)
• SQL injection in parameters → no crash, no data leak
• IDOR: User A can't access User B's data by changing an ID
• Missing auth token → 401 (not 200 or 500)
• SQL injection in parameters → no crash, no data leak
• IDOR: User A can't access User B's data by changing an ID
🧨 Negative Testing
What happens when things go wrong?
• Missing required fields → 400/422, clear error message
• Invalid types (string where number expected)
• Non-existent resources → 404, not 500
• Missing required fields → 400/422, clear error message
• Invalid types (string where number expected)
• Non-existent resources → 404, not 500
⚡ Performance Testing
Does it hold up under load?
• Response time under threshold (e.g. <300ms)
• Concurrent requests handled without errors
• Rate limiting returns 429 when exceeded
• Response time under threshold (e.g. <300ms)
• Concurrent requests handled without errors
• Rate limiting returns 429 when exceeded
📄 Contract Testing
Does the response match the documented spec?
• All documented fields present, correct data types
• Field names exact match (case-sensitive!)
• No undocumented fields leaking sensitive data
• All documented fields present, correct data types
• Field names exact match (case-sensitive!)
• No undocumented fields leaking sensitive data
Q — QA DETECTIVE
"IDOR, Watson — Insecure Direct Object Reference. Change
/users/42 to /users/43 while authenticated as user 42. If you get user 43's data — critical security bug. Escalate immediately."QUICK CHECK
Section 4
You test GET /orders/101 while logged in as User A. The order belongs to User B. The API returns full order details with 200 OK. What type of bug is this?
Think security testing categories.
Q — QA DETECTIVE
LESSON 05 · TOOLS
Postman — the QA detective's toolkit
Postman is the most widely used API testing tool. It lets you send HTTP requests, inspect responses, write assertions, and automate test suites — no code required (though you can add it).
🔧 Collections
Group related requests by feature. Run the whole collection with one click. Share with your team.
🌍 Environments
Switch between
dev, staging, prod using variables. Never hardcode URLs.✅ Tests tab
Write JS assertions after each request.
pm.test(), pm.expect(). Automated checks on every run.🔄 Newman
Run Postman collections from command line. Integrate into CI/CD. No GUI needed.
Postman — QALingo Practice
GET
Params
Headers
Body
Tests
KEYVALUE
userId42
KEYVALUE
AuthorizationBearer {{token}}
Content-Typeapplication/json
No body for GET requests.
// Postman test scripts (JavaScript)
pm.test("Status is 200", () => {
pm.response.to.have.status(200);
});
pm.test("Has id field", () => {
pm.expect(pm.response.json()).to.have.property('id');
});
pm.test("Response under 300ms", () => {
pm.expect(pm.response.responseTime).to.be.below(300);
});
Response
Hit "Send" to fire the request...
Test Results
✓
Status is 200✓
Has id field✓
Response under 300ms?
Authorization validatedQUICK CHECK
Section 5
You want your Postman collection to run automatically every time a developer pushes code to GitHub. What makes this possible?
Think about the command-line version of Postman.
Q — QA DETECTIVE
🕵️ DETECTIVE CASE FILE #001
The Login API — 6 Tests You Must Run
The situation: You're testing a new login endpoint before it goes to production. Endpoint:
POST /auth/login. It accepts email + password, returns a JWT token on success. Find the bugs before users do.1
Valid email + correct password → 200 OK + token in response2
Valid email + wrong password → 401 Unauthorized (not 500)3
Missing password field → 400 Bad Request with clear error message4
SQL injection in email field → no crash, no data leak5
Valid credentials but account locked → 403 Forbidden with reason6
50 rapid login attempts → 429 Too Many Requests (rate limiting active)Q — QA DETECTIVE
"Tests 1-3: functional. Test 4: security — never skip on auth endpoints. Test 5: business logic. Test 6 — rate limiting — is what separates junior QAs from senior ones. Most people forget it. Attackers don't.
If test 2 returns 500 instead of 401, that's a bug. If test 4 crashes or leaks data — escalate immediately."
If test 2 returns 500 instead of 401, that's a bug. If test 4 crashes or leaks data — escalate immediately."
EXPECTED RESULTS
Test 1: POST { email, password } → 200 + { token: "eyJ..." }
Test 2: POST { email, wrongPass } → 401 { error: "Invalid credentials" }
Test 3: POST { email } → 400 { error: "password is required" }
Test 4: POST { email: "' OR 1=1--" } → 400/401 (no crash)
Test 5: POST (locked account) → 403 { error: "Account suspended" }
Test 6: 50x rapid → 429 { retryAfter: 60 }FINAL CHECK
Section 6
In an interview: "How would you test an API without any documentation?" — Best answer?
Think like a detective, not a script follower.
Q — QA DETECTIVE
🏆
+0 XP
Module Complete, Watson.
"QAlemental. You now test APIs like a detective — not like a tourist."
0/6
CORRECT
6
SECTIONS
🔌
API TRACK
REFERENCE
API Testing Cheat Sheet
🔢 Status Codes
200 OK · 201 Created · 204 No Content400 Bad Request · 401 Unauthorized403 Forbidden · 404 Not Found409 Conflict · 422 Unprocessable429 Too Many Requests · 500 Server Error🔑 HTTP Methods
GET — Read (idempotent)POST — Create (returns 201)PUT — Full replacePATCH — Partial updateDELETE — Remove (204 or 200)🧪 Always Test
✓ Happy path (valid data)
✓ Missing required fields
✓ Invalid data types
✓ Auth missing/invalid
✓ IDOR (access other user's data)
✓ SQL injection
✓ Rate limiting
✓ Missing required fields
✓ Invalid data types
✓ Auth missing/invalid
✓ IDOR (access other user's data)
✓ SQL injection
✓ Rate limiting
🛠 Tools
Postman — GUI API testingNewman — CLI runner / CI-CDSwagger — API docs & contractcurl — Command line requestsRestAssured — Java automationpytest + requests — Python