Test automation practice: does your API suite catch the bugs?

Write automated tests for a small REST API and run them against nine builds of it. Build 0 follows the reference. Builds 1 to 8 have one planted bug each or none, and the page does not say which. Mark where your suite failed, and the check tells you which bugs it caught and where it failed on a build that had nothing wrong with it.

• Any tool that sends HTTP requests will do: pytest with requests, REST Assured, Playwright's request API, Postman with Newman.
• A failure on a build with a bug is a catch. A failure on a clean build counts as a false alarm.
• Two checks along the way give counts. The final check shows every build and its bug.
• Each session draws its own layout: 6 or 7 bugs out of a pool of 23, spread over the eight builds.
• The check sees only your marks and trusts you to mark what the suite did.

Starting creates a session with its own tokens. The site keeps the bookings your tests create (a room, a date, two times and a number of people) for a day, and your marks. No cookies, no recording of clicks or keys.

Start the exercise

{
  "base_url": "https://chaosqa.com/api/v1",
  "builds": {
    "0": { "alice": "…", "bob": "…" },
    "1": { "alice": "…", "bob": "…" },
    …
  }
}

Your marks

Run the whole suite against each build. If any test fails, mark the build as failed. Your marks are saved in this browser.

1. Build 1failedpassed
2. Build 2failedpassed
3. Build 3failedpassed
4. Build 4failedpassed
5. Build 5failedpassed
6. Build 6failedpassed
7. Build 7failedpassed
8. Build 8failedpassed

Check my marks Submit final marks

Other exercises

• RoomBox: test the same API by hand and report the bugs
• TicketBox: a ticket order form
• JoinBox: a sign-up and login form

Guides

• REST API test cases: a checklist with examples
• Double submit testing
• All guides