How to use QA Shop for automation testing

If you have read the help index you already know what QA Shop is for. This page is the next step: a practitioner walkthrough of how we use the site ourselves when we are sitting down with a fresh laptop and an automation test suite to write.

It covers the account model, what to install on your machine, what to click through manually before you write a single assertion, and how to pick a framework when nothing on your team forces the choice. Read it linearly — there are no tabs and no clever navigation. The sidebar will get you to other help pages when you are done here.

QA Shop has four account types, but only two of them matter on day one.

The signup form for both types lives at /auth/signup; the secret-phrase field appears once you select the role.

The framework you pick will dictate most of your install list (we will get to that in a section). The constants are small.

You do not need any QA-Shop-specific environment variables to run public flows — the site is accessible without an API key. If you want to write tests that exercise admin endpoints or the REST API directly, hit /help/testing-guide for the credentials and base URLs we publish for that purpose. A deeper, framework-by-framework setup walkthrough is coming under /learn — see "Where to go from here" below.

Open the site in a fresh browser window. Click into /products and scan the catalog — note the search box, the sort and filter controls, the way out-of-stock products render. Pick a product card, click into a detail page (try /products/wireless-bluetooth-headphones-pro — it is a stable seed fixture and a reasonable test target), and find the buy box. The primary CTA carries data-testid="pdp-add-to-cart". Click it.

The cart icon updates. Click into /cart. Note the row layout — quantity controls, line totals, the data-testid="checkout-button" link that takes you to checkout.

Click through to /checkout and walk the wizard: shipping address, then payment. The payment step accepts a fixed set of test card numbers — 4242 4242 4242 4242 succeeds, 4000 0000 0000 0002 declines, 4000 0000 0000 0069 simulates an expired card. Pick the success card, complete the order, land on the confirmation page.

That is the spine of the site. Five minutes, give or take. Now you know which testids to grab, where the redirects happen, and what the confirmation page looks like — which means you can write the first version of your spec without rerunning the flow ten times to remember whether the cart redirects to checkout or just opens it.

While you are clicking around, /account/settings is worth a glance — most tests need a logged-in fixture and the settings page is the simplest "did the session stick" probe.

Four frameworks dominate the landscape. Each one has a sharp edge and a soft edge; none of them is "best." Pick the one that matches your team's constraints, and trust that the testid hooks will travel between them.

Playwright

Playwright ships locators that wait for an element to be ready before acting on it, and a parallel set of web-first assertions that retry until the condition holds or a timeout fires.¹ That auto-waiting is the single largest reason new automation engineers prefer it: the failure mode of a flaky test is "the element was not there yet" eight times out of ten, and Playwright handles that for you.

Cross-browser support is first-party (Chromium, Firefox, WebKit). If you have no constraint and you want the most forgiving learning curve, start here.

Selenium

Selenium is the standard. It is the W3C WebDriver protocol's reference implementation, and the language coverage is unmatched — Java, Python, C#, Ruby, JavaScript, and more all share the same API surface.² If your team is mixed-language, or if you are writing tests that need to run on a specific older browser version, Selenium will get you there when nothing else will.

The trade-off is verbosity: you will write more code per assertion than you would in Playwright, and you will manage waits explicitly until you build your own helpers.

Cypress

Cypress runs your test code inside the browser, which gives it a debugging experience that is hard to beat — time-travel through a failing run, see the DOM at every step, hot-reload as you edit specs.³ The price is that you are constrained to the browser's runtime: cross-origin navigation and multi-tab flows take more setup than they do in Playwright or Selenium.

For component testing and for single-app suites, Cypress is excellent; for sprawling end-to-end flows that span domains, it can fight you.

WebdriverIO

WebdriverIO is the long-tail option, and the one that pays off most when you eventually need mobile.⁴ It speaks WebDriver, so it gets the cross-browser reach of Selenium with a more modern API; and it speaks Appium, which means the same test harness can drive a real iOS or Android app.

If your roadmap has a mobile chapter, picking WebdriverIO from the start saves you a re-platforming six months in.

Whatever you pick, the testids in QA Shop are stable across all four. A spec that asserts on pdp-add-to-cart in Playwright will assert on the same selector in Selenium without translation.

Three doors out of this page.

The next stop inside the help center is /help/testing-guide — that is the reference: the full data-testid catalog, the list of stable selectors, and the test scenarios we have already validated end-to-end. After that, /help/features maps each shop capability to the user flows it unlocks, which is the right reading if you are deciding which area to automate first.

Outside the help center, /test-tools is the manual aid hub — a state inspector for cookies and JWTs, an error-simulation page for 4xx and 5xx handling, and a scenarios index that walks the high-value flows. Public, anonymous, no setup required.

For framework-specific recipes — runnable Playwright, Selenium, Cypress, and WebdriverIO setups against this exact site — head to /recipes once they are published. Longer-form practitioner content (setup walkthroughs, framework comparisons, portfolio guidance) is coming under /learn.

You can come back to this page any time. The "last verified" stamp at the bottom tells you when we last walked the flow ourselves; if it is more than a quarter old, treat anything specific (testids, card numbers, route names) the same way you would treat a Stack Overflow answer from 2018 — probably right, worth a sanity check.

Last verified: April 28, 2026