We built QA Shop because every automation tutorial we read pointed at the same demo sites — todo lists, kitchen-sink form pages, a banking app that has not been updated since 2014.
None of them exercise the parts of a real product that break tests in production: stale auth, currency formatting, stock that drops between page load and add-to-cart, redirects after login, error pages that look like success pages until you read the URL.
This site is the practice stack we wanted. It is a working e-commerce app — products, cart, checkout, orders — instrumented end-to-end with stable data-testid attributes and seeded with deterministic fixtures.
You can write a Playwright spec against it on Monday, run the same flow under Selenium on Tuesday, and the selectors you wrote for one will keep working under the other. That is the bet: invest in stable hooks, share them across frameworks, and stop rewriting boilerplate.
§ 01 · DOCS MAP
How the documentation is organized
The four cards above are the front door. Each leads into a section with its own slant.
Account types, how the Principal/Automation pairing works, and where to point your first test runner.
What the shop can do and which flow to automate first.
Useful if you are exploring the shop the way an end user would before deciding what to assert against.
The data-testid catalog, selector conventions, and the test scenarios we have already validated end-to-end.
Outside the help center, two routes do most of the work. The shop itself lives at /products — that is where you will spend most of your time writing browse-and-cart flows. The /test-tools page collects the manual aids: a state inspector for cookies, JWTs, and cart contents; an error-simulation page; and a scenarios index that walks through high-value flows.
Both are public, so you can hit them anonymously from a fresh browser context.
If a piece of documentation is older than thirty days, our voice-lint script flags it for re-verification. You will see a "last verified" stamp at the bottom of every help page, including this one.
Treat anything more than a quarter old with the same skepticism you would treat a Stack Overflow answer from 2018: probably still right, worth a sanity check.
§ 02 · THE CONTRACT
A note on selectors
Every link, button, form field, and table row in QA Shop has a data-testid. We keep them stable across releases — that is the whole product, really.
When we have to break one (renaming cart-row to cart-line-item, say), we document the change in the Testing Guide and keep the old testid as an alias for one release before removing it.
Frequently asked questions
Last verified: