Playwright Test Automation for QA Engineers

Explain the two failure modes of legacy UI automation — timing flakiness and driver overhead — and how Playwright's architecture removes each

Read and write the JavaScript constructs that appear in every Playwright test: const/let, arrow functions, template literals, destructuring, objects and arrays

Install Playwright into a new repository and into an existing front-end repository without breaking either

Run the suite, a folder, a file, a single test, a project, the last failures and only the tests affected by a change from the command line

Structure a spec file with describe blocks and the four hooks, and say when each hook runs relative to workers

Read the DOM vocabulary a locator depends on: tag, attribute, class, id, text node, parent and child

Apply the locator priority order: role, label, placeholder, text, alt, title, test id, CSS or XPath last

Use filter() with hasText, hasNotText, has, hasNot and visible to narrow a set by content, by a descendant or by visibility

Distinguish web-first assertions from generic ones and default to the former

List the actionability checks and explain which action requires which of them

Choose between fill, clear and pressSequentially by the events each one sends, and say when character-by-character typing is required

Use check, uncheck and setChecked correctly, and justify force: true on a visually hidden native input

Explain what Playwright does with a native dialog when no listener is registered, and what a registered listener is obliged to do

Automate a date picker by typing where possible and by navigating the calendar where not

State the specific duplication a page object removes and the specific change it makes cheap

Extract shared behaviour into a shallow base class — one level of inheritance — and use composition beyond that

Name the built-in fixtures and say what each provides, and explain where testInfo comes from (it is not a fixture)

Use projects to run the same tests across browsers, devices, roles and ENGAGE environments, and cap a project's parallelism with its own workers setting

Build a setup project that authenticates once and saves the session to storageState, including IndexedDB when the identity library keeps tokens there

Capture screenshots of the page, of an element and into a buffer, and attach them to the report

Write a screenshot comparison with toHaveScreenshot and manage baselines with the updateSnapshots modes and path templates

Use the request fixture to write API tests, asserting with await expect(response).toBeOK() and on headers and body

Choose between fulfill, continue, abort and fallback for an intercepted request, and explain handler order

Explain what a worker is, how work is split with and without fullyParallel, and the default number of workers

Run the suite in the official Playwright image with the recommended Docker flags, and keep the image tag equal to the installed Playwright version

Separate the pairs of Playwright concepts that are most often confused, by naming the one rule that divides each pair

Decide what to automate and at which level — unit, API, UI, visual, accessibility, journey — and defend the decision to a client