QA Shop — Product Analysis and User Stories

QA Shop is a free e-commerce system built for you to practice testing on: a real PostgreSQL database, a REST API with 41 endpoints on top of it, and a store interface that uses both. It comes up on your own machine with one command, needs no signup, and its data is real — the stock of an item you add to your cart genuinely decreases.

Practise on a real PostgreSQL and a 41-endpoint REST API: 16 user stories with acceptance criteria, business rules and a measured error catalog. No signup.

Most free testing APIs on the internet return canned responses. They are good for learning HTTP methods, status codes and reading JSON, and they remain the right tool for that. But you cannot test a business rule there: stock does not decrease, an order is never written to a table, and two users cannot see each other's data because there is no data.

What you can learn on this page

  • What does the product do? — Most testing exercises give you an endpoint that returns fake data; there, stock never drops, an order is never written to a table, and two users cannot see each other's data because there is no data. A test you write in such a place passes but proves nothing.
  • Data model — Someone who does not know why an order is written to three tables rather than two writes the "order created" check against a single table and never verifies the line items. That test passes green on a defect where the lines were never written. Knowin
  • Order lifecycle — There are six states and six allowed transitions. Every remaining combination is FORBIDDEN — and forbidden transitions are where developers slip most often, because happy-path tests never visit them. A single request like "try to ship an unpaid order"
  • Testable business rules — The only way to see that a check really looks at something is to break the rule on purpose and watch the check turn red. Because a check that always stays green and a broken check that looks at nothing are identical on a report screen. Next to each rule below
  • Error glossary — A test that says "I got a 4xx, so it works" cannot tell whether the coupon was rejected because it expired or because it was never found. Both can return the same HTTP code but point to two entirely different defects. That is why your test must asser
  • User stories — write your test cases from here — A customer browses the catalog and does not see withdrawn products
  • Testable business rules — Adding to a cart RESERVES stock, it does not decrement it · A coupon is REVALIDATED at checkout · Amount reconciliation: grand = subtotal − discount + shipping · Signing out GENUINELY revokes the session · A review is born `pending`; being saved is not the sam
  • User story list — US-01 A new customer creates an account · US-02 A customer signs in and out · US-03 A customer browses the catalog and does not see withdrawn products · US-04 A customer searches for a product · US-05 A customer adds an item and stock is reserved · US-06 A cus

Frequently Asked Questions

Is QA Shop free, and do I need to sign up?

It is free and requires no signup. The stack runs entirely on your own machine: you do not create an account, you do not buy a key, and there is no usage quota. The "sign in" step inside the system belongs to the e-commerce application you are practising on, not to this site.

How is it different from free testing APIs that return canned responses?

Those return canned responses and are good for learning HTTP methods and status codes. QA Shop has a real PostgreSQL behind it: the stock of an item you add to your cart decreases, order lines are written to a table, coupons are revalidated at checkout, and you can check the result by writing SQL in DBeaver. So here you can test business rules, not just request shapes.

What do I need to install?

Only Docker. The setup guide starts from installing Docker itself and assumes nothing is already present. If you would rather not even download the repository, you can start it from the published images with a single compose file or three docker run commands. DBeaver for SQL practice and Postman for API practice are recommended but not required.

Which kinds of testing can I practise?

All three: database testing (SQL in DBeaver, with a ready validation query suite), API testing (41 business endpoints, an OpenAPI contract, plus Postman and REST Assured sample suites) and UI automation (a store screen with stable test ids, driven by Selenium, Playwright or Cypress). Testing one business rule from three layers shows side by side what each tool makes easy and what it hides.

How do I know my test actually works?

The system has 10 controlled defects you can switch on and off. After your test passes green, you turn on the matching defect and run the same test again: if it does not go red, your test is not looking at that rule at all. A check that always stays green and a broken check that looks at nothing are identical on a report screen; the only way to tell them apart is to produce the defect deliberately.

What happens if I corrupt my data?

Nothing — corrupting it is the expected behaviour. Every user opens their own isolated data area, and nobody can see or damage anyone else's data. One request returns you to the seed data, so you can put the reset into your suite's setup step. Keep in mind that the reset shifts row ids and revokes open sessions.