Playwright JS —
From Beginner to Automation Engineer in 33 Days

Playwright is now the industry's fastest-growing automation tool — adopted by Microsoft, Google, and hundreds of product companies globally. Setting it up correctly from the start, especially understanding async/await and the {page} fixture, means every module that follows will make immediate sense. Companies hiring for Playwright roles expect you to be able to initialise and run a project from scratch in an interview.

You cannot automate something you do not understand. Knowing that every web element is a piece of HTML with a tag, attributes, and text is what makes every locator module possible. The playwright → browser → context → page hierarchy is also how Playwright isolates test sessions — understanding it prevents hours of debugging when you later run tests in parallel or manage multiple tabs.

Playwright's smart locators (getByRole, getByLabel, getByText) are designed to survive UI redesigns — they look for meaning, not HTML structure. Using them means your tests keep working even when developers change a button's class or ID. This is the approach Playwright's own documentation recommends first, and what experienced automation engineers reach for before writing a single XPath.

CSS is the fastest locator strategy in Playwright and often the most readable — #login-btn is much cleaner than a long XPath. Understanding partial match operators like *= and ^= is especially useful when element IDs are generated dynamically (e.g. item-4892) — you can target just the stable prefix. CSS is also the backbone of the :has-text() pseudo-class used heavily in test filtering.

XPath is the most powerful locator strategy — it is the only one that can match elements by their text content, navigate up to parent elements, and handle completely dynamic pages. Every automation engineer needs it in their toolkit for situations where CSS and smart locators fall short. Understanding contains() and and/or/not is what separates a capable engineer from one who gets stuck on hard pages.

Most real-world automation challenges involve dynamic tables, e-commerce listings, and dashboards where prices, statuses, and IDs change every page load. The IE & DE pattern — anchor to something stable, navigate to something dynamic — is the professional solution. This is exactly the technique used in production frameworks to automate complex data-entry and verification tasks that no other locator strategy can handle.

Real applications show dozens of similar elements — rows in a table, cards in a grid, items in a list. Filtering lets you target the exact one you need without brittle index numbers. And iFrames appear constantly in the real world: payment gateways, embedded maps, chat widgets, and social login buttons all live inside frames. Being comfortable with frameLocator is what makes you productive on real projects from day one.

Locators tell Playwright what to interact with — actions tell it how. The 33 methods here cover every possible browser interaction. Knowing the difference between fill() (clear then type) and pressSequentially() (key by key) matters for applications that validate input as you type. The trace viewer is the single most powerful debugging tool in Playwright — being able to replay a failure step by step is what makes you fast at fixing broken tests.

Dropdowns, alerts, and popups appear in virtually every real application — login pages, forms, confirmation dialogs, and checkout flows all use them. selectOption is simpler than Selenium's Select class. And the trick to handle JS alerts — registering a listener with page.once before triggering the action — is one of the most commonly asked interview questions for Playwright roles.

Modern QA roles expect you to test both the UI and the API. Playwright's built-in request fixture means you never need a separate tool like Postman in your automation suite. More practically, setting up test state via API (creating a user, seeding data) is dramatically faster than doing it through the browser — and it makes your UI tests more reliable because there is less setup that can go wrong.

Flaky tests — tests that sometimes pass and sometimes fail — are the biggest productivity killer in automation. The root cause is almost always a timing problem: the script moved faster than the page. Understanding the difference between a blind waitForTimeout (slow, unreliable) and a smart waitFor or waitForLoadState (fast, reliable) is what separates test suites that just work from ones that need constant babysitting.

Without assertions a test cannot pass or fail — it can only run. Playwright's expect API is unique because it retries automatically until the condition is true or the timeout expires, eliminating most timing-related false failures. Knowing when to use soft assertions (collect all failures at once) versus hard assertions (stop at first failure) is a sign of professional test design that interviewers specifically ask about.

Data-driven testing is what transforms a single test into a full test suite with one file. Instead of writing 50 login tests for 50 users, you write one and drive it from an Excel sheet. Parallel execution then runs all 50 in the time it used to take to run 5 — dramatically reducing the feedback loop for developers. These two skills together are what make automation genuinely useful to a team rather than a curiosity.

This is where everything comes together. The B149_AFW framework is a production-ready automation suite — the same pattern used in professional QA teams at product companies. By the end you will have a real GitHub repository with POM classes, data-driven tests, Allure reports, and Jenkins integration. This is the portfolio project that turns interviews from "tell me about automation" into "let me show you my framework".