QASubsection
Automation
Three browser tools, each explained through the one architectural fact that produces everything else about it. Playwright controls a browser from outside over a single connection; Cypress runs inside the tab with your application; Selenium is a published W3C standard with libraries attached. Read the architecture and the feature lists explain themselves — including the parts each tool cannot do. What belongs in a browser test at all is on the E2E page, not here.
What is inside
Every page in this group, with what each one covers.
- PlaywrightOne shop’s twelve journeys in Playwright and the config that runs them in four minutes, the browsers it really runs, traces.Auto-waitTraces
- CypressThe same twelve journeys in Cypress — seven native, five workarounds — the command queue and retry-ability since Cypress 12.Retry-abilityOne tab
- SeleniumThe same twelve journeys and who supplies each, then the run only Selenium can add: the shipped browsers, Safari on an iPhone included.Real SafariGrid
Where to start
- Starting a new suitePlaywright. It is the reasonable default in 2026, and its page states the caveats rather than leaving you to find them.
- Front-end developers own the testsCypress — read the twelve verdicts first: if your journeys stay on one origin it fits, and component testing is its strongest part.
- The browsers customers actually runSelenium — start with the twelve journeys and line 2.3: the shipped Safari, on a Mac and on an iPhone, is the check only WebDriver reaches.
Elsewhere in the section
- QAQuality assurance is the practice of deciding what to check, running those checks often enough to be worth having, and knowing what changes when the thing under test stops giving the same answer twice. This section covers 9 topics in three groups: the types of testing everyone half-remembers, automation with Playwright, Cypress and Selenium, and testing products built on language models — where an assertion becomes a score rather than an equality.
- Types of TestingThree tests that people put on one list and that are not comparable. Smoke is a gate: it decides whether a build is worth anyone else’s time. Regression is memory: it remembers what already broke once. End-to-end is the journey: it is the only place the assembled system can be proved to work, from start to finish. The first two are reasons to run tests and can be written at any level, which is the distinction most interview answers miss.
- DevOpsGetting a change from a developer’s machine to a running system, repeatably and without ceremony. Three topics that stack: the pipeline that decides whether a change is safe, the image format that makes "it works on my machine" a testable claim, and the scheduler that keeps the result running. Each page is about the mechanism rather than a tool’s configuration syntax, which is what transfers when you change tools.
Found this useful?
Share it with someone who is working on the same problem.