API Testing Mistakes Interns and Junior QAs Make (and How to Avoid Them)

1. Treating "200 OK" as proof that the API works

What it looks like

You send a request, get a green 200 status, and mark the test as passed.

Why it hurts

A status code only says the server replied. The reply could contain an empty list, the wrong user's data, a missing field, or an error message wrapped inside a success code.

How to avoid it

Treat the status code as the first check, never the last. Always verify the response body: do the required fields exist, are the values correct, and are the data types right?

Rule of thumb: if you only checked the status code, you checked about 10% of the response.

2. Testing only the happy path

What it looks like

Every request has perfect data, a valid token, and sensible values.

Why it hurts

Real users (and real attackers) don't behave perfectly. Most production bugs live in the edges: empty fields, huge inputs, wrong data types and expired sessions.

How to avoid it

For every endpoint that accepts input, build a small "bad input" set:

• A required field missing
• An empty string or null
• The wrong data type (text where a number belongs)
• A very long value
• Special characters
• A missing, wrong or expired token

Then check that the API returns the right error status (like 400, 401, 403 or 404) with a clear message.

3. Testing without reading the API documentation first

What it looks like

You start sending requests and guess what the API should do.

Why it hurts

Without a clear idea of what "correct" means, you can't tell a bug from normal behavior. You either miss real bugs or report fake ones.

How to avoid it

Before testing, read the API documentation or Swagger spec and write down, in plain words, what each endpoint should accept and return. If the documentation is missing or unclear, ask. A question costs two minutes; a wrong assumption can cost days.

4. Hardcoding URLs, IDs and tokens

What it looks like

The full server URL and a token are pasted into every request.

Why it hurts

The day the environment changes, or the token expires, you have to edit dozens of requests, and you will miss one. Hardcoded values are also how secrets end up in screenshots and shared files.

How to avoid it

Use environment variables for anything that can change: base URL, tokens, IDs and API versions. In Postman, that means writing {{base_url}} instead of the full address.

5. Leaking tokens and secrets by accident

What it looks like

A screenshot in a bug report shows a live token. A collection is exported and sent to a colleague with real credentials inside. A password sits in a shared chat.

Why it hurts

Anyone who sees a valid token can use it. This is one of the most common accidental security problems on small teams, and interns are not the only ones who do it.

How to avoid it

• Keep secrets in the current value of variables, or mark them as secret type
• Blur or remove tokens from screenshots before sharing
• Check exported files before sending them
• If a secret leaks, tell your lead immediately so it can be replaced. Reporting it quickly is the right move, not something to hide

6. Writing API tests that can never fail

What it looks like

A test like this one:

pm.test("Test passes", function () {
    pm.expect(true).to.be.true;
});

Why it hurts

A test that always passes gives false confidence. It looks like protection but protects nothing.

How to avoid it

After writing any test, try to break it on purpose. Change the expected value, then run it. If it doesn't turn red, it isn't testing anything. A good test is one you have personally seen fail.

7. Running tests in the wrong environment

What it looks like

You run tests against the live (production) server because it was the URL in front of you.

Why it hurts

Creating, editing or deleting data on a real system can affect real users. Even "harmless" test requests can send real emails, trigger real payments or fill real databases with junk.

How to avoid it

Always check which environment is selected before pressing Send. Make the environment name obvious (Dev, Staging), and never run write operations (POST, PUT, DELETE) on production unless your team has explicitly approved it.

8. Ignoring headers, response time and error messages

What it looks like

You only glance at the main data and skip the headers, the response time and the error messages.

Why it hurts

Important problems hide there: a missing Content-Type, a response that takes six seconds, an error message that exposes internal details, or a header that shows the wrong cache setting.

How to avoid it

Make a habit of scanning four things on every response: status, time, headers and body. Over time, you will start noticing things that look "slightly off", and that instinct is what makes a good tester.

9. Writing vague bug reports

What it looks like

"The API is not working." or "Login fails sometimes."

Why it hurts

A developer can't fix what they can't reproduce. Vague reports create back-and-forth messages and delay the fix.

How to avoid it

Write reports another person could follow without asking you anything:

• Title: short and specific, such as "POST /orders returns 500 when quantity is 0"
• Environment: where you tested
• Steps: the exact request, body and headers (with secrets removed)
• Expected result: what should have happened
• Actual result: what really happened, with the status code and response
• Evidence: a screenshot or the response text

A good bug report often gets fixed faster simply because it is easy to understand.

10. Being afraid to ask questions

What it looks like

You are stuck for hours but stay quiet because you don't want to look unprepared.

Why it hurts

Time passes, the task stalls, and small confusions grow into big mistakes. Teams almost never judge an intern for asking; they judge silence that leads to wrong results.

How to avoid it

Use the 20-minute rule. Try on your own for 20 minutes, using the documentation, the Postman Console and a search. If you are still stuck, ask, and bring what you have already tried. That shows effort and makes it easy for someone to help you quickly.

Quick fixes at a glance

• Trusting the 200: always verify the response body
• Happy path only: add a bad-input set to every endpoint
• Skipping the docs: write down what "correct" means first
• Hardcoded values: use environment variables
• Leaked secrets: use secret variables and clean screenshots
• Tests that never fail: break the test on purpose once
• Wrong environment: check the environment before every Send
• Ignoring details: scan status, time, headers and body
• Vague bug reports: include steps, expected result, actual result and evidence
• Silent struggling: try for 20 minutes, then ask

A practical API testing checklist

Before saying an API is "tested", you should be able to answer these questions:

Do I understand what the API should do?

Have I read the documentation and written down what correct behavior looks like?

Have I tested more than the happy path?

Did I check the status code and the response body, at least one invalid input, and one authentication failure?

Is my setup safe and repeatable?

Are my URLs and tokens in variables, and is nothing sensitive visible in my screenshots or exports? Was I on the correct environment?

Can I trust my tests and my reports?

Have I seen my main tests fail at least once when I broke them on purpose, and could someone else reproduce my bug reports?

If these questions cannot be answered clearly, there is probably more testing to do.

Final takeaway

Everyone makes these API testing mistakes at the start. What matters is how quickly you notice them. Treat each one as a free lesson, build the checklist into your routine, and you will soon be the person on the team others come to when they say, "Can you double-check this API?"