Exploratory test a REST API with boundary thinking
Run a structured exploratory testing session against a real REST API (JSONPlaceholder, Reqres, or the GitHub API). You will map the API surface, write a session charter, explore boundary conditions and error handling with Postman or curl, and file at least three bug reports or observations with exact reproduction steps.
Why this matters
Most API bugs are not found by the developer's happy path test suite. They live at the boundaries: what happens when you send 10,000 characters in a name field? What happens when you send an integer where a string is expected? An exploratory tester who can think like an adversary and document findings rigorously adds more coverage than ten automated scripts for the happy path.
Before you start
- Postman (free) or curl installed
- Access to a REST API with documentation; JSONPlaceholder, Reqres.in, or the GitHub API all work
- Basic understanding of HTTP methods (GET, POST, PUT, DELETE) and status codes
- Familiarity with JSON
Step-by-step guide
- 1
Map the API surface
Read the API documentation and list every endpoint, HTTP method, path parameter, query parameter, and request body field. Note which fields are required vs optional, and their documented types and constraints. This map is your testing surface; every item on it is a test vector.
- 2
Write a session charter
Use the format: 'Explore [endpoint group] with [Postman] to discover [error handling and boundary behaviour].' Time-box to 45 minutes. Identify 3 specific questions you want to answer by the end of the session.
- 3
Test the happy path first
Send valid requests to each endpoint and verify responses match documentation. Confirm status codes, response body shape, and header values. Any happy path failure is a critical bug; document it before exploring further.
- 4
Probe boundaries and error handling
Systematically explore: empty strings for required fields, null values, negative numbers, very long strings (10,000 characters), unexpected types (send an array where a string is expected), special characters (SQL injection patterns, Unicode, emoji). Record every request and the exact response.
- 5
Check error response consistency
Find 5 different ways to trigger a 4xx error. Compare the error response bodies; are they in the same format? Do they include error codes and human-readable messages? Inconsistent error responses are a usability bug and an integration risk for API consumers.
- 6
File your findings
Write at least 3 bug reports or observations from the session. Each should include: the exact HTTP request (method, URL, headers, body), the actual response, what you expected, why the actual response is a problem, and a severity classification.