REST API Testing — CRUD Validation

Test a public REST API end-to-end: CRUD operations, status code validation, schema checking, authentication, and error handling — using any HTTP tool or language.

Role

API tester

Difficulty

Intermediate

Time limit

90–120 min

Scenario

You have been given access to a public REST API for a task management system (e.g. JSONPlaceholder, Reqres.in, or a provided Postman mock). Your task is to validate the API's correctness by designing and executing a test plan covering the full CRUD lifecycle for the /users and /posts (or equivalent) resources. The development team has asked for a written test plan + execution evidence before the API is integrated with the front-end.

Requirements

1.Test all four CRUD operations (Create, Read, Update, Delete) for at least one resource
2.Validate HTTP status codes for every request (both success and expected error cases)
3.Validate response body structure using JSON schema validation or explicit field-level assertions
4.Test at least 3 error/edge cases: missing required field, invalid ID, unauthorised request (if auth is available)
5.Test at least one chained scenario: create a resource, read it back, update it, verify the update, delete it, verify it is gone
6.Document your test plan: resource under test, test case ID, endpoint, HTTP method, input, expected status, expected body shape
7.Provide execution evidence: exported Postman collection, test script output, or screenshot of results

Starter data

›API base URL: https://jsonplaceholder.typicode.com (no auth required — use for structure/schema tests)
›Alternatively: https://reqres.in (supports auth token — allows testing 401/403 scenarios)
›Resources available: /users (id, name, email, address, phone, website, company), /posts (id, userId, title, body), /comments, /todos
›JSONPlaceholder note: it is a fake API — mutations (POST/PUT/DELETE) return correct status codes and response shapes but do NOT persist data
›Reqres.in note: POST /api/login returns a token you can use for authenticated endpoints

Expected deliverables

✓A written test plan (spreadsheet or Markdown) listing every test case with: ID, endpoint, method, input payload, expected status code, expected response shape
✓Execution evidence: exported Postman/Bruno collection OR test script with run output (copy of terminal output or test runner report)
✓A defect report for any actual failures found (even on the mock API — e.g. unexpected field names, incorrect status codes)
✓A 3–5 sentence summary of your observations: what was well-designed about the API, what was ambiguous or inconsistent

Evaluation rubric

Dimension	What reviewers look for
Status code coverage	Are 2xx, 4xx, and relevant 5xx status codes tested? Is the correct code asserted (201 vs 200 for Create, 204 vs 200 for Delete)?
Schema / field validation	Are response fields checked by name, type, and optionality — not just 'the response has a body'? Are nullable fields tested with null inputs?
Chained scenario	Does the chain test demonstrate that the resource lifecycle is consistent end-to-end? Does it clean up after itself (delete the created resource)?
Error path quality	Are error scenarios technically accurate? Does the 'missing required field' test omit a truly required field rather than an optional one? Is the expected error message verified?
Test plan clarity	Could a colleague re-execute the test plan from the document alone, without asking clarifying questions? Are inputs and expected results specific enough to be deterministic?
Observations	Does the summary show API design awareness? (e.g. noticing that PUT returns 200 rather than the more correct 204, or that error bodies lack a consistent structure)

Sample solution outline

›TC-001 GET /users — 200, array of user objects, each with id (integer), name (string), email (string) — field-level assertions on first item
›TC-002 GET /users/1 — 200, single user object with all expected fields present
›TC-003 GET /users/9999 — 404, response body is empty or contains an error object
›TC-004 POST /users — 201, response contains the submitted fields plus a new auto-generated id
›TC-005 POST /users with missing 'name' field — 400 or 201 (note: JSONPlaceholder accepts it — document the behaviour)
›TC-006 PUT /users/1 — 200, response body reflects the updated values
›TC-007 DELETE /users/1 — 200 or 204, subsequent GET /users/1 returns 404 (on a real API) or 200 (document JSONPlaceholder behaviour)
›TC-008 Chained scenario: POST /posts → capture returned id → GET /posts/{id} → PUT /posts/{id} with new title → GET /posts/{id} → assert updated title → DELETE /posts/{id}
›TC-009 GET /users?id=1 — 200, filtered array containing only user 1
›TC-010 POST /api/login (Reqres) with invalid credentials — 400, error field in body

Common mistakes

Only testing GET requests — the most common gap in candidate take-homes is skipping POST, PUT, and DELETE
Asserting only the status code and ignoring the response body structure — 'got a 200' is not the same as 'got the correct data'
Not testing the DELETE-then-GET pattern — proving the resource is gone is as important as deleting it
Writing test cases for a resource field that is optional and then treating it as a failure when it is absent
Confusing response body schema validation with asserting a specific value — schema says 'email is a string'; value assertion says 'email is test@example.com'; both are needed for different things
Forgetting to handle the JSONPlaceholder note that mutations are faked — the solution outline explicitly documents this as expected behaviour, not a defect

Submission checklist

Test plan document with all required columns: ID, endpoint, method, input, expected status, expected shape
At least one test per CRUD verb (GET, POST, PUT/PATCH, DELETE)
At least 3 error/edge case tests
At least one chained scenario covering the full lifecycle
Execution evidence (collection export or script + output)
Defect report (even if empty — 'No defects found' with a brief justification is valid)
3–5 sentence API quality summary

Extension ideas

+Write a parametrised test that verifies GET /users/{id} for ids 1–10 returns consistent schema for all valid users
+Add a performance assertion: assert that all GET requests respond within 500ms
+Write a contract test: define a JSON Schema for the user object and validate all users in the collection against it