Selenium to Playwright: the SDET roadmap

The goal of day one is not understanding — it is a green test running in three browsers so you have something to modify.

• Install with npm init playwright@latest and read what the scaffolder generated
• Understand the architecture: one WebSocket connection to the browser, not an HTTP driver per command
• Write and run your first test with npx playwright test
• Run the same test on Chromium, Firefox and WebKit without changing a line
• Live in the UI mode runner: npx playwright test --ui
• Generate a test with npx playwright codegen — then rewrite it by hand

WebDriverManager.chromedriver().setup();
WebDriver driver = new ChromeDriver();
driver.manage().timeouts()
  .implicitlyWait(ofSeconds(10));
driver.get("https://example.com");
// ... test ...
driver.quit();

test('opens the site', async ({ page }) => {
  await page.goto('https://example.com');
  // no driver, no waits, no teardown
});

Three ideas carry the whole tool: a test is a function that receives fixtures, a locator is a lazy query, and an assertion retries. Everything else is detail.

• test, expect, locator — and why a locator is not an element
• Built-in fixtures: page, context, browser, request
• Read playwright.config.ts line by line — projects, use, reporters, webServer
• Test isolation: every test gets a fresh browser context, so state never leaks
• Hooks and grouping: describe, beforeEach, test.step
• Annotations: skip, fixme, fail, slow, and tagging tests

If you take one stage seriously, make it this one. Locator strategy is the single largest predictor of how much time you will spend maintaining the suite in year two.

• getByRole() with an accessible name — your default, not your fallback
• getByLabel(), getByPlaceholder(), getByText(), getByAltText()
• getByTestId() — and agreeing with developers on the attribute
• Chaining and narrowing: .filter(), .and(), .or(), .nth()
• Strictness: why "resolved to 2 elements" is the framework protecting you
• When CSS or XPath is still the honest answer

driver.findElement(By.xpath(
  "//div[@class='form']//button[2]"
)).click();

await page
  .getByRole('button', { name: 'Save' })
  .click();

Every action performs actionability checks first: the element must be visible, stable, enabled and able to receive events. This is the feature that deletes most of your wait code.

• click(), fill(), check(), selectOption(), setInputFiles()
• hover(), dragTo(), and when you need page.mouse instead
• Keyboard: press() vs type() vs fill() — and why fill() usually wins
• Screenshots and video: per-element, full page, and on-failure capture
• Trace viewer — record a trace, open it, step through a failure

Web-first assertions retry until they pass or time out. Used properly, they replace essentially every explicit wait you have ever written.

• Visibility and state: toBeVisible(), toBeHidden(), toBeEnabled(), toBeChecked()
• Content: toHaveText(), toContainText(), toHaveValue(), toHaveCount()
• Page level: expect(page).toHaveURL(), toHaveTitle()
• Soft assertions, and expect.poll() for non-DOM conditions
• Retries and timeouts: test, expect, action, and global — know which is which

new WebDriverWait(driver, ofSeconds(10))
  .until(ExpectedConditions
    .visibilityOfElementLocated(By.id("msg")));
assertEquals("Saved",
  driver.findElement(By.id("msg")).getText());

await expect(page.getByTestId('msg'))
  .toHaveText('Saved');

Everything above works on a demo site. This stage is the difference between a tutorial and a suite that runs against your actual product.

• Dialogs: page.on('dialog') — and the fact that they are auto-dismissed by default
• Iframes with frameLocator() — no context switching, no switching back
• New tabs and popups via the page event, not a window-handle loop
• Native selects vs custom dropdown components
• Uploads with setInputFiles(), downloads via the download event
• Network interception with page.route() — stub, delay, fail, inspect
• Authentication once via storageState and a setup project
• Dynamic content: infinite scroll, polling widgets, animated transitions

String parent = driver.getWindowHandle();
for (String h : driver.getWindowHandles()) {
  if (!h.equals(parent)) driver.switchTo().window(h);
}
// ... and remember to switch back

const [popup] = await Promise.all([
  page.waitForEvent('popup'),
  page.getByRole('link', { name: 'Docs' }).click(),
]);
await expect(popup).toHaveTitle(/Docs/);

This is where Selenium experience becomes an asset again — design instincts transfer even when the APIs do not. Just start smaller than you think you need to.

• Page objects the modern way: locators as properties, no wait helpers, no PageFactory
• Custom fixtures — the real replacement for base classes and inheritance
• Test data: factories over spreadsheets, and data that a parallel run cannot collide on
• Environment config: projects, baseURL, and per-environment overrides
• Reporting: the HTML reporter, blob for merging shards, Allure if the business asks
• Structuring a repo other people can contribute to without asking you first

// fixtures.ts
export const test = base.extend<{ checkout: CheckoutPage }>({
  checkout: async ({ page }, use) => {
    const checkout = new CheckoutPage(page);
    await checkout.gotoWithItems(2);
    await use(checkout);           // test runs here
  },
});

// the test asks for what it needs — nothing to inherit
test('applies a discount', async ({ checkout }) => {
  await checkout.applyCode('SAVE10');
  await expect(checkout.total).toHaveText('$45.00');
});

None of these are mandatory. Each one is worth a day the moment your project needs it — and knowing they exist is what stops you building a worse version by hand.

• API testing with the request fixture — set up state in one call instead of ten clicks
• Parallelism: workers, fullyParallel, and sharding across CI machines
• Visual comparison with toHaveScreenshot() and a sane baseline policy
• Mobile emulation and device descriptors
• Accessibility scanning inside your existing suite
• Component testing — where it beats an end-to-end test outright
• Playwright MCP: driving a real browser from an AI assistant for exploratory work

A suite that only runs on your machine is a personal hobby. This stage turns it into something the team relies on.

• Run in a container with the official Playwright image — no browser install drift
• A GitHub Actions or Jenkins pipeline triggered on pull requests
• Publish the HTML report and make the link visible on the PR
• Upload artifacts: traces, videos and screenshots for failures only
• Shard across runners and merge blob reports into one
• Scheduled runs against staging, with a real alert when they break

The suite you finish this quarter is the suite you maintain for three years. These are the habits that decide whether that is pleasant.

• Track flaky tests as defects with owners, not as background noise
• Watch total suite runtime like a production metric
• Read the release notes — the API moves faster than most tools you have used
• Delete tests that have never failed for a real reason
• Teach one colleague the locator rules; the suite is only as good as its worst contributor