Home/ Techniques/ Senior/ API Testing
Senior · Integration Technique

API Testing

Test the "Headless" app. API testing is the most powerful way to verify business logic, security, and performance before the first pixel is even drawn on the screen.

Senior ISTQB CTAL-TA 3.3 — K3 Apply ~15 min read + exercise

1 The Hook — The "Invisible" Logic

Imagine a bank vault. You can see the door (the UI), but the actual gears that unlock it are hidden behind the wall (the API). If you only test the door handle, you might not notice that the gears inside are grinding or that the combination lock is broken.

Modern apps are "Headless" — the brain (API) is separate from the face (UI). API testing allows you to talk directly to the brain. It's faster, more reliable, and can find critical security bugs that UI testing can't even touch. If the API is correct, the UI just needs to display it.

2 The Rule — Method, Status, Body

Every API test must verify the "Triple-Check": Status Code, Headers, and Response Body.

A good API test follows this pattern:

  • The Request: Method (GET, POST), URL, and Payload (JSON).
  • The Response: Status Code (200, 404), Headers (Auth), and Body (Data).

3 The Analogy — The Burger Order

Analogy

The Waitstaff vs. The Chef.

When you order a burger, the **Waitstaff** (UI) takes your order. They might be friendly or have a nice uniform, but they don't cook the burger. They take your "Request" to the **Chef** (API) in the kitchen. The Chef doesn't care if the Waitstaff is wearing a nice apron; they just care if the "Order Ticket" (JSON) says "No Onions." If the Chef cooks it wrong, it doesn't matter how good the Waitstaff is. API testing is testing the Chef directly.

4 Watch Me Do It — NZ Bank Validation

Scenario: You're testing a NZ Payment API that accepts a bank account number (BB-bbbb-AAAAAAA-SS).

  • Create Request: POST /payments with body {"account": "06-0000-0000000-00"}.
  • Verify Status: Expect 201 Created.
  • The Guess: What if I send an Australian 16-digit card number instead?
  • Create Request: POST /payments with body {"account": "4564...1234"}.
  • Verify Status: Expect 422 Unprocessable Entity.
  • The Security Check: What if I try to view someone else's payment?
  • Create Request: GET /payments/999.
  • Verify Status: Expect 403 Forbidden. Bug Found! (If it returns 200).

5 Decision Tool — API vs. UI Testing

✅ Use API Testing for...

  • Speed: Runs in milliseconds.
  • Stability: Doesn't break when CSS changes.
  • Security: Testing Auth and IDOR.

🖼 Use UI Testing for...

  • Layout: Is the button visible?
  • UX: Is the flow intuitive?
  • End-to-End: Does the whole app work?

6 Common Mistakes

🚫 Only testing the "Happy Path"

I used to think: I got a 200 OK, so I'm done.
Actually: The most important API tests are the 400s and 500s. Does the system crash if you send letters instead of numbers? Does it expose secret data in the error message?

🚫 Hardcoding IDs

I used to think: I'll just use GET /order/123 forever.
Actually: Data changes. Your test should Create an order (POST), save the ID, and then Retrieve that specific ID (GET). This is called "Request Chaining."

7 Now You Try — Choose the Status Code

🎯 Interactive Exercise

Scenario: You try to view an order that doesn't exist in the database.

What is the correct HTTP Status Code the API should return?

8 Self-Check

Q1. What is the difference between a 401 and a 403 status code?

401 Unauthorised: I don't know who you are (Login required).
403 Forbidden: I know who you are, but you aren't allowed to see this (Permission denied).

Q2. What is "Idempotency"?

It means sending the same request twice should have the same result as sending it once. For example, clicking "Delete Order" 10 times should only delete it once and return 204 or 404 for the rest, not crash the server.

9 Interview Prep

"How do you test an API for security vulnerabilities?"

Answer: "I look for four things: 1. Authentication (can I reach it without a token?), 2. Authorization (can I see other users' data via IDOR?), 3. Input Validation (can I send SQL or XSS payloads?), and 4. Information Disclosure (does a 500 error leak the database version or stack trace?)"