Getting Started & Architecture
Understand why Playwright is different, how its architecture enables true cross-browser testing, and scaffold your first test in TypeScript or Java.
Getting Started & Architecture video demo
A practical screen-share style walkthrough for chapter 1, showing how the Playwright idea works in TypeScript and Java.
Briefing focus
Why Playwright, and why now?
This is a structured lesson briefing. Real video/audio can be added later as a media source.
Estimated time
10 min
- 1Why Playwright, and why now?
- 2Install & scaffold
- 3Your first Playwright test
Transcript brief
Understand why Playwright is different, how its architecture enables true cross-browser testing, and scaffold your first test in TypeScript or Java. The video brief explains the mental model first, then demonstrates the workflow using the course code samples, and finishes with reliability checks you can apply in CI.
Key takeaways
- Translate the concept into a maintainable Playwright test.
- Understand the TypeScript and Java equivalents without changing the test intent.
- Avoid the common source of flaky or slow end-to-end tests for this topic.
Why Playwright, and why now?
Playwright is a browser automation framework built by the original Puppeteer team at Microsoft. It talks directly to Chromium, Firefox and WebKit through a single API over the DevTools Protocol, making it genuinely cross-browser. Unlike Selenium, it ships its own browsers, its own drivers, and an architecture designed for modern web apps.
- Playwright runner
- The test runner that drives browsers, manages parallel workers, collects traces, videos and screenshots.
- Browser context
- An incognito-like isolated session. Each test gets its own context — no cookie or storage leakage between tests.
- Page
- A single tab within a context. All interactions (click, fill, navigate) flow through a Page object.
- Locator
- Playwright's first-class way to refer to an element. Locators auto-retry and re-evaluate on every use.
Install & scaffold
# Scaffold a new project
npm init playwright@latest
# Pick TypeScript, pick the GitHub Actions workflow when prompted.
# Playwright downloads Chromium, Firefox and WebKit binaries.
# Run the example test
npx playwright test
# Open the HTML report
npx playwright show-reportYour first Playwright test
// tests/homepage.spec.ts
import { test, expect } from '@playwright/test';
test('homepage has a CTA', async ({ page }) => {
await page.goto('https://qatraining.uk');
await expect(page.getByRole('heading', { name: /master software testing/i })).toBeVisible();
await page.getByRole('link', { name: /start learning/i }).click();
await expect(page).toHaveURL(/\/learn/);
});Real-life scenario · Retail SaaS
Switching from Cypress — a 2-week story
Situation. A mid-sized retailer ran 900 Cypress tests at 40 minutes per full run. Flaky rate: 14%. They migrated the smoke-pack to Playwright in a 2-week spike. Results: run time dropped to 8 minutes on 6 parallel workers, flakiness fell to 1.1%, and the team gained free Firefox/WebKit coverage.
Lesson. Tool choice is strategy, not preference. Playwright's architecture — one process, many contexts, parallel by default — is purpose-built for modern apps.
Exam tip
Know the roles: Browser → Context → Page → Locator. Contexts are cheap, browsers are expensive — so Playwright creates one browser per worker and many contexts per test.