Assert the contract, not just the status
A 200 response can still contain the wrong ID, missing properties, or unexpected data types. The collection checks meaningful fields as well as status codes.
QA CASE STUDY / API TESTING
Testing API contracts
beyond status codes.
A practical review of the Postman + Newman portfolio project: how the scenarios were chosen, which response risks were covered, and what the latest recorded CI execution demonstrated. This is an independent portfolio project against the public JSONPlaceholder demo API, not client or production work.
PostmanNewmanREST APIJavaScript assertionsGitHub Actions
01 / EXECUTION SNAPSHOT
Observed in the recorded CI run.
The successful GitHub Actions run on 11 October 2026 executed the collection against the public demo service.
7Requests executed
24Assertions executed
0Failed assertions
25 msAverage response time in this run
This is one execution snapshot, not a performance benchmark or a guarantee of future results. The same run recorded a 323 ms total collection duration and individual response times from 15–76 ms.
02 / TEST OBJECTIVE
What needed to be validated?
A successful HTTP status alone doesn't confirm a response is usable. The checks also validate response format, required fields, types, values, and selected negative paths.
Test question: Does each representative API response meet the contract expected by a consuming client, including errors and CRUD-style demo responses?
03 / RISK-BASED COVERAGE
Scenarios selected and why.
HIGH / DATA
List and retrieve users
Validate status, JSON content type, non-empty list response, required user fields and their types, and the requested ID for a single-user response.
HIGH / NEGATIVE
Missing user and unknown route
Check service-specific not-found behaviour instead of assuming every invalid resource returns the same response shape across all APIs.
MED / CONTRACT
Create and update a post
Check the documented success status and verify returned IDs and relevant fields match the request or intended updated values.
MED / RESPONSE
Delete response
Validate the expected success response while tolerating either an empty body or an empty JSON object, both observed as compatible response forms for this demo.
CROSS-CUTTING
Response quality and timing
Check content type and a configurable response-time threshold alongside the business-relevant body assertions. Timing checks here are lightweight guardrails, not load or stress testing.
04 / TEST DESIGN DECISIONS
Why these checks matter.
Keep expectations service-specific
Missing-resource behavior and delete response bodies can differ by API. Expectations are documented against JSONPlaceholder and should be re-baselined if the target changes.
Make execution repeatable
The collection runs locally with Newman and in GitHub Actions, with a JUnit report artifact available from the run.
State limitations clearly
JSONPlaceholder simulates write operations. Successful POST, PUT, and DELETE responses do not prove that data persisted on the server. Authentication, security penetration, and load testing are outside this project's scope.
05 / REPRODUCIBLE EVIDENCE
Inspect the actual project.
Recorded GitHub Actions run7 requests · 24 assertions · 0 failures
Open run ↗
JUnit report artifactDownloadable CI report from the recorded run; GitHub artifact retention applies
Open artifact ↗
Request-level coverage matrixScenario IDs and assertions by endpoint
View matrix ↗
Postman collectionInspectable requests and test scripts
View collection ↗
06 / RELATED UI AUTOMATION
The other automated suites.
Recent recorded workflow results are listed below; use the run logs to inspect exact scenarios and evidence.
Playwright / TypeScript11 tests passed in the recorded run on 11 Oct 2026
Open run ↗
Cypress + Cucumber BDD12 scenarios passed in the recorded run on 11 Oct 2026
Open run ↗
All three projects use public demo environments. Results represent particular runs and can change as the demos, credentials, network, or repository configuration change.