8
API Testing Mistakes
That Keep QA Engineers
Stuck at Junior Level
Aston Cook
Senior QA Automation Engineer
01
Only Testing the Happy Path
THE MISTAKE
You send valid data, get a 200 response, and call it done.
WHY IT HURTS
Real users will send empty strings, null values, special characters, and data types you never
imagined. APIs break at the edges, not the center.
THE FIX
For every endpoint, test: empty inputs, null values, boundary values, wrong data types, SQL
injection strings, and absurdly long inputs.
02
Ignoring Response Time
THE MISTAKE
The API returns correct data, so you mark the test as passed.
WHY IT HURTS
An API that takes 8 seconds to respond is broken, even if the data is perfect. Users will
abandon your app before the response arrives.
THE FIX
Add response time assertions to every test. Set thresholds based on your SLAs. A 200ms
endpoint suddenly taking 2 seconds is a bug.
03
Hardcoding Test Data
THE MISTAKE
Your tests use the same user ID, email, and product ID every single run.
WHY IT HURTS
Hardcoded data creates false positives. Your tests pass because the database happens to
have that exact record, not because the API works.
THE FIX
Generate unique test data for each run. Use factories, fixtures, or API calls to create fresh
data. Clean up after yourself.
04
Testing in Isolation Only
THE MISTAKE
Each endpoint is tested independently with mocked dependencies.
WHY IT HURTS
APIs live in ecosystems. The payment endpoint might work perfectly in isolation but fail when
the inventory service returns unexpected data.
THE FIX
Layer your testing: unit tests for logic, integration tests for service communication, and
end-to-end tests for critical user flows.
05
Skipping Authentication Edge Cases
THE MISTAKE
You test with a valid token and move on.
WHY IT HURTS
Auth failures are where security vulnerabilities hide. Expired tokens, malformed tokens,
missing scopes, and revoked access all need testing.
THE FIX
Test: expired tokens, invalid signatures, missing headers, wrong user permissions, rate
limiting, and token refresh flows.
06
Not Validating Response Schema
THE MISTAKE
You check if the status is 200 and maybe verify one field.
WHY IT HURTS
A missing field or wrong data type can crash your frontend. Schema changes are silent killers
that slip through status code checks.
THE FIX
Use JSON Schema validation or tools like Ajv. Validate every field, data type, and required
property. Catch contract breaks before production.
07
Forgetting Error Response Testing
THE MISTAKE
You only verify what happens when things go right.
WHY IT HURTS
Error handling is where user experience lives or dies. A generic 500 error with no helpful
message is a support ticket waiting to happen.
THE FIX
Test every error scenario: 400 for bad input, 401 for auth failures, 404 for missing resources,
429 for rate limits. Verify error messages are helpful.
08
No Environment Parity
THE MISTAKE
Tests pass in dev but you skip staging because 'it works locally.'
WHY IT HURTS
Production has different data volumes, network latency, and configuration. The API that
handles 10 records might choke on 10,000.
THE FIX
Run your full test suite against staging with production-like data. Test performance under
realistic load. Trust but verify.
Found this helpful?
Save this for your next API testing project.
Follow for more QA tips every week.
Aston Cook
Senior QA Automation Engineer @ Resilience