Business Analysis · Modern QA
Playwright vs Old Tools: What Changed for Business Analysts
Quick summary — Playwright vs old tools for BAs
Playwright collapsed the gap between acceptance criteria and automated tests. BAs no longer write screen-by-screen test scripts — they write behavior-driven specs that Playwright can execute directly.
In this guide you will learn:
- What was wrong with Selenium / QTP-era specs.
- What Playwright changed for BAs.
- How to write specs that Playwright can automate.
- Best practices for BA-QA collaboration.
- Interview Q&A + quiz to test your readiness.
SECTION 01The old workflow — Selenium + manual specs
Before Playwright, most QA teams used Selenium + a mix of manual scripts, spreadsheets, and QTP-style recording tools. It worked — but broke at scale, and BAs often felt like passive spec writers.
- Brittle locators: tests broke on any DOM change — QA and BA spent days fixing test scripts.
- Explicit waits everywhere: flaky tests meant re-runs and false failures.
- Two-track specs: BAs wrote acceptance criteria; QA wrote separate test scripts — often diverging.
- Manual screenshots: every spec update required a new Excel or Confluence redraw.
- Slow feedback: automated tests took hours — so teams relied on manual QA for critical flows.
- Cross-browser pain: Selenium Grid setup was heavy and unreliable.
SECTION 02What Playwright changed for BAs
Playwright's biggest innovation isn't the code — it's the reliability. That single change reshapes how BAs write specs because specs no longer rot.
| Area | Old (Selenium / QTP) | Playwright |
|---|---|---|
| Waits | Explicit sleep() / wait | Auto-wait built-in |
| Locators | XPath / CSS brittle locators | User-facing selectors (role, label, text) |
| Test flakiness | High — 15–30% reruns common | Dramatically lower |
| Cross-browser | Grid complexity | Built-in via browser parameter |
| Debugging | Logs + screenshots | Trace viewer, video recording |
| Test spec | Separate from acceptance criteria | Behavioral spec ≈ test |
| Language | Java + Selenium | TypeScript / Python / Java |
| CI/CD | Custom setup | First-class support |
| BA involvement | Indirect via test plan docs | Direct — BDD-style acceptance tests |
Feature: Login and redirect to dashboard
Acceptance Criteria:
1. When a user enters valid credentials,
Then they see the dashboard within 2 seconds.
2. When a user enters invalid credentials,
Then they see an inline error "Invalid email or password"
AND the form remains on screen.
3. When a user submits the form empty,
Then validation messages appear under both fields
AND no API call is made.
4. When 5 failed attempts happen within 5 minutes,
Then the account is locked for 15 minutes
AND a message "Account locked" is shown.
// Playwright test — same criteria, executable
import { test, expect } from '@playwright/test';
test.describe('Login flow', () => {
test('valid credentials redirect to dashboard', async ({ page }) => {
await page.goto('/login');
await page.getByLabel('Email').fill('user@x.com');
await page.getByLabel('Password').fill('pass123');
await page.getByRole('button', { name: 'Log in' }).click();
await expect(page).toHaveURL(/dashboard/, { timeout: 2000 });
});
test('invalid credentials show inline error', async ({ page }) => {
await page.goto('/login');
await page.getByLabel('Email').fill('user@x.com');
await page.getByLabel('Password').fill('wrong');
await page.getByRole('button', { name: 'Log in' }).click();
await expect(page.getByText('Invalid email or password')).toBeVisible();
await expect(page.getByRole('button', { name: 'Log in' })).toBeVisible();
});
test('empty form shows validation messages', async ({ page }) => {
let apiCalled = false;
page.on('request', r => {
if (r.url().includes('/api/login')) apiCalled = true;
});
await page.goto('/login');
await page.getByRole('button', { name: 'Log in' }).click();
await expect(page.getByText('Email is required')).toBeVisible();
await expect(page.getByText('Password is required')).toBeVisible();
expect(apiCalled).toBe(false);
});
test('5 failed attempts lock the account', async ({ page }) => {
await page.goto('/login');
for (let i = 0; i < 5; i++) {
await page.getByLabel('Email').fill('user@x.com');
await page.getByLabel('Password').fill('wrong');
await page.getByRole('button', { name: 'Log in' }).click();
await page.waitForTimeout(200);
}
await expect(page.getByText('Account locked')).toBeVisible();
});
});
SECTION 03How to write specs that Playwright automates
Good Playwright specs have 5 characteristics. Write your acceptance criteria with these in mind and QA can automate them in 1 day, not 1 week:
- Behavioral, not UI-implementation: "user sees error" not "red span with class error appears".
- Accessible naming: describe elements by role and label (button, "Log in") — Playwright finds them reliably.
- Given-When-Then format: makes the sequence of actions and expected outcome obvious.
- Explicit state changes: what changes on screen or API — Playwright tests can assert these directly.
- No hidden timing assumptions: "within 2 seconds" not "after sleep 3s" — Playwright's auto-wait handles timing.
GOOD — Playwright-friendly acceptance criteria
Scenario: User adds product to cart
GIVEN the user is on the product page for "iPhone 15"
WHEN the user clicks the "Add to Cart" button
THEN the cart badge shows "1"
AND the "Add to Cart" button shows "Added to cart"
AND the user can click "View Cart" to go to the cart page
Why this works:
- Uses role + name ("Add to Cart" button)
- Behavioral assertions (badge shows "1")
- Clear next action (View Cart button)
BAD — not Playwright-friendly
Scenario: User adds product to cart
GIVEN the user is on product page
WHEN they add to cart
THEN it works correctly
Why this fails:
- "Product page" — which product?
- "Add to cart" — where's the button?
- "It works correctly" — un-testable, no observable state
- No clear success criteria
getByRole("button", {name: "Add to Cart"})
needs an actual button with that label.
SECTION 04Best practices for BA-QA collaboration
Playwright changes the BA-QA dynamic. Here's how successful teams work together:
| Practice | What it looks like | Why it helps |
|---|---|---|
| Co-write acceptance criteria | BA + QA + dev write scenarios together | Specs that Playwright can automate from day 1 |
| Review test failures together | BA reviews failed test names | Bugs found are user-facing |
| Use accessible labels in specs | "Click 'Save' button" not "Click the blue button" | Matches Playwright's locators exactly |
| Update specs with every UI change | Any UI tweak = spec update | Prevents test breakage drift |
| Review Playwright traces together | BA + QA on weekly trace review | BA understands where automation caught real bugs |
| Track tests as features | Each acceptance test ties to a ticket | Visible coverage for stakeholders |
SECTION 05Common mistakes to avoid
- Writing specs for UI layouts — describe behavior and outcomes, not CSS or DOM.
- Using vague success criteria — "works correctly" is not testable; "badge shows 1" is.
- Ignoring accessibility labels — Playwright finds elements by label; if labels are missing, tests break.
- Treating specs as static docs — update specs alongside UI changes, not after.
- Not reading test failures — failed tests are your fastest feedback loop as a BA.
- Skipping trace reviews — the trace file is the best bug demo tool you'll ever see.
SECTION 06Interview Q&A — Playwright for BAs
Q1What's the biggest change Playwright brought for BAs?
Specs and tests became unified. Before, BAs wrote acceptance criteria as documents and QA wrote separate scripts. With Playwright's resilient locators and auto-waits, acceptance criteria can directly translate into automated tests — so BAs now write specs QA can automate directly.
Q2How do I write acceptance criteria that Playwright can automate?
Use behavioral language, accessible element names (button + label), and clear success states. Given-When-Then format works best. Avoid CSS classes, colors, or DOM structure references.
Q3Do BAs need to write Playwright code?
No — but understanding the structure helps enormously. A BA who can read a Playwright test file writes 10× better acceptance criteria, and can review automated test failures with QA much more effectively.
Q4What's a Playwright trace and why should BAs care?
A trace is a recording of every step, network call, and DOM snapshot of a test run. When a test fails, the trace shows exactly what happened — like a replay. BAs who review traces understand what automation caught and can refine specs.
Q5Why is Playwright better than Selenium for BA-QA collaboration?
Reliability. Selenium tests break often; BAs lose trust in automation and fall back to manual testing. Playwright's auto-waits and resilient locators make tests trustworthy — so both BA and QA trust the automation's signal.
SECTION 07Test yourself — Playwright for BAs quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
Do BAs need to write Playwright tests?
No. BAs write acceptance criteria; QA engineers write the tests. But understanding Playwright's structure — especially role + label selectors — helps BAs write specs that don't require translation.
Is Playwright better than Selenium?
For new projects, yes — Playwright's auto-waits, modern selectors, and trace viewer are dramatically better. Selenium is still used in legacy enterprise systems. For BA-QA collaboration, Playwright's reliability is a game-changer.
What's the best way to learn Playwright as a BA?
Don't code it — just read the docs and look at test files your QA team writes. Ask them to explain 2–3 test files. That understanding is enough to write dramatically better acceptance criteria.
What about BDD tools like Cucumber?
BDD tools like Cucumber still exist, but Playwright's built-in structure is often enough — no extra Cucumber layer needed. Some teams use Playwright + Gherkin; both approaches work. Focus on writing testable specs, not on tool choice.
How does Playwright help with test coverage discussions?
Playwright's test reports and trace files make test coverage visible. BAs and stakeholders can see exactly which acceptance criteria have automated tests — and which are still manual. That visibility drives better prioritisation.
SECTION 09Related reads
Classroom & online · Noida
Become a BA who understands modern QA
Our Business Analysis + Modern QA programme covers behavior-driven specs, Playwright fundamentals, and real BA-QA workflows.
₹15,500 · full programme- BDD-style specs
- Playwright for BAs
- Real enterprise projects
- Weekday & weekend batches




