Resources

The wider test automation tool landscape

Selenium, Cypress, WebdriverIO, Appium and the rest: what each is genuinely good at, from a source that is not neutral.

10 resources9 from official documentationTools

A disclosure before the list, because it changes how you should read it: QAright is built on Playwright, so we are not a disinterested party. What follows is our honest reading of where each tool is strong, and the documentation links are the projects' own. Where we think something beats Playwright at a job, that is said.

Tool	Strongest at	The real cost
Playwright	Modern web apps, cross-browser, tracing, CI ergonomics	Younger ecosystem; fewer people have it on a CV
Selenium	The W3C standard, every language, every browser, grids, legacy and enterprise estates	Waiting and stability are your problem to solve
Cypress	Developer experience, a superb interactive runner, front-end teams testing their own app	Runs inside the browser, which constrains tabs, origins and native events
WebdriverIO	A large plugin ecosystem, and web plus mobile through one runner	Configuration surface is broad
Appium	Native and hybrid mobile, which the browser tools do not do	Device management is most of the work

The uncomfortable truth about tool choice is that it matters much less than the things this section cannot sell you: whether your locators describe intent, whether the suite runs on every push, and whether anyone reads the report. A team with those three habits succeeds on any of the tools above. A team without them fails on all of them, and then migrates, and then fails again.

Migrating is rarely the answer to flakiness

Suites are usually flaky because of implicit waits, positional locators and shared state, and all three migrate perfectly well to the new tool. If a migration is on the table, fix a dozen of the worst tests first. Sometimes the migration stops being necessary; when it does not, you at least arrive with better tests.

Browser automation

5 entries

Selenium documentation
Official docs

The project that defined browser automation and still the basis of the W3C WebDriver standard. Worth reading whatever you use, because most of the industry's vocabulary — and most of the interview questions — come from here.
www.selenium.dev
WebDriver (W3C specification)
Standard

The actual standard underneath Selenium and several others. Dry, and the definitive answer when two drivers disagree about what a command should do.
www.w3.org
Cypress documentation
Official docs

Excellent documentation, and the interactive runner is genuinely the nicest debugging experience in the category. Read the “trade-offs” page in their own docs early; it is unusually honest about the architectural limits.
docs.cypress.io
WebdriverIO
Official docs

A test runner and automation framework with a large plugin ecosystem, able to drive both WebDriver and Chrome DevTools protocols, and web plus mobile from one place.
webdriver.io
Puppeteer
Official docs

Chrome and Firefox only, and a lower-level API than the others. Better than a test framework when what you actually want is scripted browser work: scraping, PDF generation, screenshots.
pptr.dev

Mobile, and the things browsers cannot reach

2 entries

Appium
Official docs

Native, hybrid and mobile-web automation across iOS and Android, using the same WebDriver protocol. The only mature open-source answer for real native apps, and the device farm is the hard part rather than the API.
appium.io
Playwright: emulation
Official docs

Not a substitute for a real device, and listed because most “mobile” bugs are layout bugs. Emulated viewports, touch, locale and colour scheme catch those in seconds.
playwright.dev

Runners and assertion libraries

3 entries

The thing that actually decides what a failure message looks like.

Vitest
Official docs

A fast runner for JavaScript and TypeScript with a Jest-compatible API. Where the unit and component layer of the pyramid lives in most current front-end projects.
vitest.dev
pytest
Official docs

The Python standard, and worth knowing for fixtures and parametrisation even if you never write Python: both concepts show up, renamed, in most other runners.
docs.pytest.org
NUnit
Official docs

The .NET runner Playwright's own base classes target, with a mature constraint-based assertion model and a well-documented parallelisation story. The attributes for parameterised cases are worth knowing before hand-rolling a loop.
docs.nunit.org

What to take away

Tool choice matters less than three habits.Intent-revealing locators, running on every push, and someone reading the report.
Read the trade-offs page in the tool's own docs.The good projects publish theirs. That is a strong signal in itself.
Fix the worst dozen tests before migrating.Flakiness usually migrates with you.

Missing something? If there is a resource you send to every new tester on your team, tell us and we will read it. The list stays short on purpose; each entry has to earn its place, and entries that stop earning it get removed rather than left to rot.

Reading is the slow way to learn how a suite behaves. Record one against your own app, free, and watch what the report says.

Get started free See how it works