Testing Practice Playground: practise QA automation on real sandboxes
The best way to learn test automation is to point it at something real and slightly broken. Here are eight free sandboxes — four UI, four API — each with a specific mission, and a method that turns clicking around into practice a hiring manager will actually look at.
The fastest practice needs no download and no flaky demo server — it runs in this tab. Start here, then take the muscle memory to the real sandboxes below.
Every list of "sites to practise automation" is the same twenty links with one sentence each, and half of them 404. The links aren't the hard part — knowing what to do when you get there is. So this page is short on sites and long on missions: eight sandboxes that are actually up, each with a specific job to do and a way to make it harder once it's easy.
Practise so it counts
Opening a demo site and clicking around is not practice. These four moves are what turn it into something you can show:
- 01One target, one skill
Site-hopping feels productive and teaches nothing. Pick a single sandbox and a single skill — robust waits, the CRUD loop, pagination — and stay there until it's solid.
- 02Write the plan before the code
The sandbox won't tell you what "correct" means — you decide. One paragraph of what you'll check and what you're deliberately not checking, before the first line of automation.
- 03Automate the unhappy path
Anyone can automate the login that works. The marks are in the locked-out user, the 404, the missing token, the empty cart. Happy-path-only is the top reason a take-home gets rejected.
- 04Ship it with a README
A green test on your machine proves nothing to a hiring manager. Push it to a public repo with a README saying what it covers and how to run it — now it's a portfolio piece.
UI sandboxes
Browser automation — the flows, the tricky elements, the data on the page. Start with SauceDemo for a clean end-to-end run, then go to The Internet the moment you want to fix flakiness rather than write more of it.
SauceDemo
saucedemo.comA stubbed e-commerce store (Swag Labs) with six logins — including deliberately broken ones. The default first target.
The end-to-end UI flow every automation interview expects — log in, add to cart, check out — plus your first taste of a target that behaves badly on purpose.
Your missionAutomate the whole purchase as one test: log in as standard_user, add two named items, assert the cart badge count, complete checkout, and assert the confirmation. Then run the same test as problem_user and locked_out_user — your job is to make each failure report why, not just go red.
Data-drive it. Read the usernames from a list, loop the login test over all of them, and assert the expected outcome per user. That's the difference between one script and a suite.
Open saucedemo.com ↗
The Internet
the-internet.herokuapp.comFifty-odd isolated pages, each one tricky UI behaviour — dynamic loading, iframes, JS alerts, file upload, shifting content. The selector gym.
Robust waiting and locator strategy. This is where flaky tests are born and fixed. Nothing here is a flow; each page is a controlled experiment in one thing that breaks scripts.
Your missionDo Dynamic Loading → Example 2 without a single hard-coded sleep — wait for the element, not the clock. Then accept and dismiss a JavaScript alert, and read a value out of an iframe (the Frames examples). If your test contains sleep(3), you haven't finished.
The Challenging DOM and Shifting Content pages exist to punish brittle selectors. Write locators that survive an id changing on every load — relative, text- or role-based, never a copied absolute XPath.
Open the-internet.herokuapp.com ↗
BooksToScrape
books.toscrape.comA fake bookshop — 1,000 books across 50 pages with prices, star ratings and stock. A static, never-changing catalogue.
Pagination, extraction and data validation. The catalogue never changes, so it's the calm place to learn to walk many pages and assert on structured data instead of just "it loaded".
Your missionWalk all 50 pages, collect every book's title, price and rating, and assert three things: the count is exactly 1,000, no price is £0.00, and every rating is one of One–Five. Turn "it loaded" into "the data is correct."
Level it upIts sister site quotes.toscrape.com adds a login and an infinite-scroll variant — run the same extraction against content that arrives as you scroll rather than as you paginate.
Automation Exercise
automationexercise.comA full, realistic e-commerce site — registration, search, cart, checkout — that also publishes a documented list of test API endpoints for the same domain.
The bridge. One site where you automate a UI journey and hit a REST endpoint about the same data — exactly how a real SDET works across both layers.
Your missionRegister a new account through the UI (throwaway email), then confirm it through the site's /verifyLogin API from its API list. The UI creates the state; the API asserts it. That two-layer check is a genuinely senior habit.
Its API list ships endpoints that should fail — wrong method, missing parameter. Call those on purpose and assert the error response. Negative API testing is where the marks are.
Open automationexercise.com ↗API sandboxes
No browser, just requests and responses. Work down the list — no auth, then a key, then full token CRUD, then a contract to read. As a warm-up, httpbin.org echoes back whatever you send, which is the quickest way to see headers, status codes and auth schemes in isolation before you assert on anything.
JSONPlaceholder
jsonplaceholder.typicode.comThe no-friction fake REST API — posts, comments, users. No key, no login, returns instantly. Your first API test with nothing in the way.
Request and response, status codes, and JSON-body assertions — learned before anything asks you to authenticate.
Your missionGET /posts/1 and assert the status is 200 and the body has userId, title and body. Then POST a new post and assert you get 201 with the fields you sent echoed back. Two requests, and you understand the shape of every REST test.
It fakes writes — a POST returns 201 but nothing persists. Notice that. Knowing the difference between a stubbed API and a stateful one is exactly the trap this site teaches you for free.
Open jsonplaceholder.typicode.com ↗
ReqRes
reqres.inA hosted fake REST API with realistic users, pagination and deliberate delays. Since its 2025 relaunch, every request needs a free API key.
Realistic REST plus your first authentication header. The key requirement is a feature, not a bug — it's the gentlest possible introduction to sending credentials with a request.
Your missionGrab the free key, then send it as an x-api-key header on GET /api/users?page=2. Assert the page, per_page and the length of the data array all agree. Then hit /api/users/23 and assert a 404 — the "not found" path most people forget.
The ?delay= parameter makes it respond slowly on purpose — use it to prove your timeout handling is real, not just lucky. (A 401 means your key header is missing; check that first.)
Restful Booker
restful-booker.herokuapp.comA CRUD booking API built for testing — token auth, ten seeded bookings, and, in the author's words, "loaded with a bunch of bugs." Resets every ten minutes.
The full API lifecycle: authenticate, create, read, update, delete — and find planted bugs. The closest free thing to a real API-test brief.
Your missionPOST to /auth for a token, create a booking, then GET it back and assert every field survived the round trip. Update it with PUT (needs the token) and DELETE it. That create → verify → update → delete loop is the spine of API automation.
The seeded bugs are the point. Try a PATCH that changes one field, or an update with a missing token, and see whether the API does the right thing. Write up what you find as a real bug report — /apidoc is your contract.
Swagger Petstore
petstore.swagger.ioThe canonical OpenAPI demo — a pet-store API with a full, interactive Swagger contract you can read and fire requests from in the browser.
Reading a spec. Real API work starts from an OpenAPI/Swagger document, not a tutorial — and every spec you'll meet looks like this one.
Your missionBefore any code, read the contract: find POST /pet, note its exact request schema and documented status codes. Then automate "add a pet, GET it by id, assert the name and status match." You tested against the spec — which is what a contract is for.
Send a request that breaks the schema on purpose — a missing required field, a wrong enum — and assert the API rejects it with the documented error. Contract testing is a senior skill, and this is where to rehearse it.
Open petstore.swagger.io ↗Then make it proof, not practice
A passing test on your laptop convinces nobody. The last step is always the same: put one finished project — unhappy paths covered, README written — in a public repo, and be ready to walk through why you made each call. That's what a take-home assignment is really testing, and it's what the roadmap builds toward. When you can defend one SauceDemo suite and one Restful Booker CRUD project, you're ready for the automation interview questions.
Frequently asked questions
What is the best website to practise QA automation as a beginner?
Start with SauceDemo for a UI flow and JSONPlaceholder for your first API test — both are stable and need almost no setup. Move to The Internet the moment you hit your first flaky test, because fixing that is the real skill. Or skip the setup entirely and start in the Locator Lab.
How do I practise API testing without building a backend?
Use a public sandbox API. JSONPlaceholder needs no auth at all; ReqRes adds a single free API key so you learn to send a credential header; Restful Booker gives you full token-based CRUD with bugs planted to find; and the Swagger Petstore lets you practise reading an OpenAPI contract before you test against it. httpbin.org is a useful warm-up — it echoes back whatever you send, so you can see headers and status codes in isolation.
Are these QA practice sites free?
Yes, all eight are free. One caveat: ReqRes now requires a free API key on every request since its 2025 relaunch — sign up, then send it as an x-api-key header. The others need no account. They are third-party demo servers, so treat the odd outage as normal and never enter a real password into one.
Can I put a practice project on my CV or portfolio?
Yes — and you should, but only if it's more than a happy-path script. Pick one sandbox, cover the unhappy paths, and push it to a public repo with a README that says what it covers and how to run it. That's the difference between "I did a tutorial" and a portfolio piece. Our take-home guide shows the structure reviewers score against.
Should I practise with Selenium, Cypress or Playwright?
The sandbox doesn't care — pick the tool you can explain under questioning. Reviewers weigh your test design and structure far above your framework choice. If you're undecided, Playwright has the gentlest setup for a first project; whatever you pick, write one README line saying why.
How long until practising here makes me interview-ready?
There's no honest number — it depends on where you start and how deliberately you work. What's reliable is the shape: a handful of finished projects that each cover the unhappy paths beat months of half-done tutorials. One solid SauceDemo suite and one Restful Booker CRUD project, both with READMEs, is a stronger signal than fifty scattered scripts.