Learning Objectives
By the end of this lesson you will be able to:
- Interpret the most common HTTP error status codes for validation and server failures
- Extract useful diagnostic information from error response bodies
- Use HTTP error information to write better bug reports
HTTP Status Codes as Diagnostic Signals
The HTTP status code is the server's first-level diagnosis of what went wrong. Each range has a specific meaning:
| Code Range | Meaning |
|---|---|
| 2xx | Success — request was received and processed |
| 4xx | Client error — something wrong with the request |
| 5xx | Server error — something went wrong on the server |
For testing purposes, the most important codes are:
| Code | Name | Testing Significance |
|---|---|---|
| 400 | Bad Request | The server understood the request but found the input invalid |
| 422 | Unprocessable Entity | The request was well-formed but failed business logic validation |
| 500 | Internal Server Error | The server crashed — this is almost always a bug |
| 503 | Service Unavailable | A downstream dependency (database, external service) is down |
What Good Error Responses Look Like
A well-designed error response includes:
- The correct HTTP status code
- A machine-readable error code or category
- A human-readable message
- Optionally: which field caused the problem
Example of a good 422 response:
{
"error": "VALIDATION_ERROR",
"message": "Divisor cannot be zero",
"field": "divisor"
}
Example of a bad 500 response:
{
"timestamp": "2024-01-15T10:30:00",
"status": 500,
"error": "Internal Server Error",
"message": "/ by zero",
"trace": "java.lang.ArithmeticException: / by zero\n\tat ..."
}
The bad 500 means the server wasn't designed to handle this case — it crashed instead of validating.
Reading a 500 Response Body
When you get a 500, the response body often contains a stack trace. This is valuable:
- Error type:
ArithmeticException: / by zero— tells you what type of error occurred - Location:
at CalculationService.java:47— tells you exactly where in the code it happened (application layer) - Cause: From the trace, you can often infer whether the error is in the application code or the database
The Test Result Documentation Format
For every error response you observe, document:
Status: 422
Body: {"error": "VALIDATION_ERROR", "message": "Divisor cannot be zero"}
Assessment: Correct behavior — input was validated before computation
or
Status: 500
Body: {"message": "/ by zero", "trace": "ArithmeticException at CalculationService:47"}
Assessment: BUG — server crashed instead of validating. Division was attempted before
divisor=0 was checked. Application-layer failure.
Pro Tip: HTTP 500 with "ArithmeticException" in the body is almost always a bug you should report. The server received invalid input, didn't validate it, tried to compute with it, and crashed. That's a defect at the application validation layer.
Key Takeaways
- 4xx = client error (your input was wrong, but the server handled it)
- 5xx = server error (the server crashed — almost always a bug)
- Read the response body, especially for 5xx — the stack trace is a diagnostic tool
- Document status code + body + your assessment in your test records