QA Engineer project
Build an API test suite that covers negative cases and asserts on real content
Happy paths, validation errors, auth failures, and edge cases against a real API — graded on whether assertions check the actual response, not just the status code.
The brief
Build an automated API test suite (using a JS or Python test framework) against a public or sample API. Cover happy paths, validation errors (missing or invalid fields), auth failures, and at least one edge case per endpoint (an empty list, a pagination boundary, a duplicate-resource attempt). Assertions should check the response body's actual shape and content, not only the status code.
Suggested stack
What you hand in
- A public GitHub repository with the test suite and a README
- The README lists which endpoints and cases are covered
- Tests can be run with a single documented command and produce a clear pass/fail summary
Grading happens against the rubric below, so read it before you start — not after.
How this is graded
Published in advance and weighted out of 100. Nothing here is a surprise.
Tests exist for missing/invalid fields, auth failures, and at least one edge case per endpoint, not only the happy path.
Assertions verify the response body's shape and specific field values, not just that the status code was 200.
Each test can run on its own or in any order without depending on state left behind by a previous test.
Each test's purpose is clear from its name or a comment, so a failure is easy to interpret without re-reading the implementation.
No console errors or crashes, no broken layout, no leftover placeholder text or commented-out code.
Why this project is worth your weekend
- Most junior QA portfolios only test the happy path, and interviewers specifically probe for negative-case thinking because that's where real bugs live.
- Asserting on response shape, not just status code, is what catches a backend regression that still returns 200 with the wrong data.
- Independent, order-agnostic tests are what makes a suite usable in CI, rather than a fragile script that only works run start to finish.
Where people lose points
- Only testing that valid requests return 200, with no test for a missing required field or an invalid type.
- Asserting only the status code and never checking that the response body actually contains the right data.
- Tests that depend on running in a specific order (test 2 assumes test 1 already created a resource), so they break the moment one is run alone.
Other QA Engineer projects
Two or three of these turn an empty resume into a portfolio.
Built it? Get it scored against this rubric.
Submit your work and get a score on every criterion above, written feedback, and three resume bullets you can use straight away.