The card below is the “product under test”. Use guided mode to see the bug list upfront, or blind mode to find them yourself first.
Techniques: API testing, Boundary value analysis
API contract vs actual response
CONTRACT (expected):
GET /api/users/42
200 OK
{
"id": 42,
"email": "user@example.com",
"name": "Aroha Williams",
"role": "editor",
"created_at": "2024-01-15T09:00:00Z",
"active": true
}
ACTUAL response:
GET /api/users/42
200 OK
{
"user_id": 42,
"email": "user@example.com",
"full_name": "Aroha Williams",
"role": "EDITOR",
"createdAt": "15/01/2024",
"password_hash": "$2b$10$abc123...",
"active": 1
}
Your findings
0 / 0 bugs foundTick each bug as you confirm it on the page above. Progress saves automatically.
Write down every bug you find. Be specific — where it is, what’s wrong, what it should be.
Planted bugs (6)
- Contract specifies
idbut the actual response returnsuser_id— any consumer using.idwill break. - Contract specifies
name, actual returnsfull_name— field name mismatch. - Contract specifies lowercase
editor, actual returns uppercaseEDITOR— case-sensitive consumers will fail. - Contract:
created_at: '2024-01-15T09:00:00Z'(ISO 8601). Actual:createdAt: '15/01/2024'— both the field name and date format changed. - The actual response includes
password_hash— a bcrypt hash. This field must never be returned in API responses. Critical security issue. - Contract specifies
active: true(boolean). Actual returnsactive: 1(integer). Strict type-checking consumers will fail.
API contract testing: compare every field name, every value type, every date format, and every enum value case. Also check for extra fields that shouldn't be there (like password_hash).