DEV Community: Faizal

10 Playwright Tips That Will Change How You Write Tests

Faizal — Sat, 06 Jun 2026 11:18:23 +0000

I remember the first week I seriously used Playwright.

I was migrating a 200-test WDIO suite. I thought it would take two weeks. It took four days. Not because Playwright is magic — but because once you understand how it actually thinks, everything clicks into place faster than any other tool I have used.

But I also made a lot of mistakes early on. I wrote tests the old way — the Selenium way — inside a tool that was designed for something better.

These are the 10 tips that changed how I write Playwright tests. Not the basics you find in the docs. The real stuff.

Tip 1 🎯 — Stop Using `waitForTimeout`. Seriously.

This is the first habit to break. If you are coming from Selenium or WDIO, you are used to sprinkling sleeps everywhere to handle timing issues.

Playwright has auto-waiting built into every action. When you click an element, Playwright automatically waits for it to be visible, stable, and enabled before acting. You do not need to help it.

// ❌ Old habit — never do this
await page.waitForTimeout(3000);
await page.click('#submit-btn');

// ✅ Playwright way — just click, it handles the wait
await page.click('#submit-btn');

// ✅ When you genuinely need to wait for a condition
await page.waitForSelector('#success-message', { state: 'visible' });

Every waitForTimeout in your suite is a lie you are telling yourself. Replace them all.

Tip 2 🔍 — Use `getByRole` Over CSS Selectors

Most engineers default to CSS selectors because that is what they know. But Playwright's locator methods like getByRole, getByText, and getByLabel are more resilient and closer to how a real user interacts with your app.

// ❌ Fragile — breaks when a developer changes the class name
await page.click('.btn-primary-submit-checkout');

// ✅ Resilient — targets what the user actually sees
await page.getByRole('button', { name: 'Place Order' }).click();

// ✅ Even better for forms
await page.getByLabel('Email Address').fill('test@example.com');
await page.getByRole('button', { name: 'Sign In' }).click();

These locators survive UI refactors. A developer can change every class name in the codebase and your tests will still pass because you are targeting meaning, not implementation.

Tip 3 🏗️ — Use Page Object Model But Keep It Lean

Page Object Model is still the right pattern in Playwright. But I see engineers over-engineer it — abstracting every single element into a getter, creating three layers of inheritance, building a framework that takes longer to navigate than the app itself.

Keep it lean.

// pages/LoginPage.js
export class LoginPage {
  constructor(page) {
    this.page = page;
    this.emailInput = page.getByLabel('Email');
    this.passwordInput = page.getByLabel('Password');
    this.submitButton = page.getByRole('button', { name: 'Sign In' });
    this.errorMessage = page.getByTestId('error-message');
  }

  async login(email, password) {
    await this.emailInput.fill(email);
    await this.passwordInput.fill(password);
    await this.submitButton.click();
  }
}

// In your test
const loginPage = new LoginPage(page);
await loginPage.login('user@test.com', 'password123');

One class per page. Actions as methods. Locators as properties. That is all you need.

Tip 4 🌐 — Mock Your APIs for Faster, Stable Tests

This is the most underused Playwright feature I see in real projects. Network interception is built-in, clean, and incredibly powerful. Use it to remove external dependencies from your UI tests.

// Mock an API response directly in your test
await page.route('**/api/products', async route => {
  await route.fulfill({
    status: 200,
    contentType: 'application/json',
    body: JSON.stringify([
      { id: 1, name: 'Test Product', price: 99.99 }
    ])
  });
});

await page.goto('/products');
await expect(page.getByText('Test Product')).toBeVisible();

Your UI tests should test UI behaviour. They should not fail because a third-party API was slow or returned unexpected data. Mock aggressively.

Tip 5 📸 — Use Trace Viewer When Tests Fail in CI

When a test fails in CI, most engineers look at the error message and guess. Playwright gives you something far better — a full visual trace of everything that happened.

// playwright.config.js
export default {
  use: {
    trace: 'on-first-retry',  // captures trace only when test fails
    screenshot: 'only-on-failure',
    video: 'on-first-retry'
  }
}

Then open it locally:

npx playwright show-trace trace.zip

You get a full timeline — every action, every network request, every DOM snapshot, every screenshot — in a beautiful visual interface. Debugging a CI failure goes from 2 hours to 10 minutes.

Tip 6 ⚙️ — Use `test.describe` and `test.use` for Context Isolation

One of Playwright's most powerful features is the ability to configure context at the describe block level. Use it to run the same tests across different states without duplicating code.

// Run the same checkout tests as guest and logged-in user
test.describe('Checkout — Guest User', () => {
  test.use({ storageState: undefined });

  test('should show login prompt at checkout', async ({ page }) => {
    // test logic
  });
});

test.describe('Checkout — Logged In User', () => {
  test.use({ storageState: 'auth/user.json' });

  test('should proceed to payment directly', async ({ page }) => {
    // test logic
  });
});

Clean, isolated, and no code duplication. This pattern alone will clean up suites that have grown messy over time.

Tip 7 🔐 — Save Authentication State and Reuse It

Logging in before every test is one of the biggest performance killers in UI automation. Playwright makes it trivially easy to authenticate once and reuse that session across your entire suite.

// auth.setup.js — runs once before all tests
import { test as setup } from '@playwright/test';

setup('authenticate', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill(process.env.TEST_EMAIL);
  await page.getByLabel('Password').fill(process.env.TEST_PASSWORD);
  await page.getByRole('button', { name: 'Sign In' }).click();
  await page.waitForURL('/dashboard');
  await page.context().storageState({ path: 'auth/user.json' });
});

// playwright.config.js
export default {
  projects: [
    { name: 'setup', testMatch: /auth.setup.js/ },
    {
      name: 'tests',
      use: { storageState: 'auth/user.json' },
      dependencies: ['setup']
    }
  ]
}

Tip 8 🧪 — Use `expect` Soft Assertions for Multi-Step Validations

Standard assertions stop the test the moment they fail. Sometimes you want to check multiple things on a page and see all failures at once rather than fixing them one by one. That is what soft assertions are for.

test('product page should display all details', async ({ page }) => {
  await page.goto('/products/1');

  // Soft assertions — test continues even if one fails
  await expect.soft(page.getByTestId('product-title')).toBeVisible();
  await expect.soft(page.getByTestId('product-price')).toContainText('$');
  await expect.soft(page.getByTestId('product-image')).toBeVisible();
  await expect.soft(page.getByTestId('add-to-cart')).toBeEnabled();

  // Hard assertion at the end — fails if any soft assertion failed
  expect(test.info().errors).toHaveLength(0);
});

One test run, all failures surfaced. Much faster feedback loop.

Tip 9 📊 — Tag Your Tests and Run Subsets Smartly

As your suite grows, running everything on every commit becomes too slow. Playwright's tagging system lets you run exactly the tests you need, when you need them.

test('critical checkout flow @smoke @critical', async ({ page }) => {
  // test logic
});

test('promo code validation @regression', async ({ page }) => {
  // test logic
});

# Run only smoke tests on every commit
npx playwright test --grep @smoke

# Run full regression suite nightly
npx playwright test --grep @regression

Combine this with your CI/CD pipeline and you have a smart test execution strategy — fast feedback on commits, full coverage overnight.

Tip 10 🛠️ — Use `codegen` to Bootstrap Tests, Not to Write Them

Playwright's code generator is a fantastic tool that most engineers either ignore completely or over-rely on.

npx playwright codegen https://yourapp.com

It records your browser interactions and generates test code in real time. The mistake is treating that output as finished tests. It is not. It is a starting point.

Use it to:

Quickly capture the right locators for a new page
Understand how Playwright sees your UI
Bootstrap repetitive test scaffolding

Then go back and refactor — replace fragile selectors with getByRole, extract repeated logic into page objects, add proper assertions. The codegen is your first draft, not your final test.

Wrapping Up

Playwright is genuinely one of the best automation tools available right now. But like any tool, the difference between a messy suite and a clean one is not the tool itself — it is how deeply you understand it.

These 10 tips took me months of real project work to internalize. Start applying even two or three of them today and you will notice the difference in how your tests feel to write, maintain, and debug.

The best Playwright suite is one your whole team trusts. Build towards that.

Written by **Abdulfaizal Shaikh* — Senior Automation Engineer with 7+ years of experience building production automation frameworks across UI, API, and mobile platforms.*

WDIO vs Playwright — An Honest Comparison from Someone Who Has Used Both

Faizal — Sat, 06 Jun 2026 10:18:59 +0000

I have a confession.

For a long time I was a WDIO loyalist. I had built entire frameworks on it, trained teammates on it, and defended it in every "what tool should we use?" conversation. Then a project pushed me to use Playwright seriously — and I had to completely reassess my opinions.

This is not a "Playwright wins, delete WDIO" article. Both tools are genuinely excellent. But they are excellent in different ways, for different teams, in different situations.

After using both in real production environments, here is my honest take.

A Quick Introduction for Context

WebdriverIO (WDIO) has been around since 2012. It is built on the WebDriver protocol, supports an enormous plugin ecosystem, and is battle-tested across thousands of enterprise projects. It feels like a mature, opinionated framework that has seen everything.

Playwright was released by Microsoft in 2020. It uses its own browser automation protocol, ships with everything built-in, and was clearly designed by people who were frustrated with the limitations of older tools. It feels like a fresh start.

Both are JavaScript-first. Both support TypeScript. Both are actively maintained. That is where the easy comparisons end.

Round 1 🚀 — Getting Started

WDIO

Setting up WDIO is guided but verbose. The CLI wizard walks you through configuration choices — framework, reporter, services — and generates a config file that can easily reach 100+ lines before you write a single test.

// wdio.conf.js — just the basics
export const config = {
  runner: 'local',
  specs: ['./test/specs/**/*.js'],
  capabilities: [{
    browserName: 'chrome'
  }],
  framework: 'mocha',
  reporters: ['spec'],
  mochaOpts: {
    timeout: 60000
  }
}

There is power in that config — but for a new team, it is a lot of decisions upfront.

Playwright

Playwright's setup is remarkably fast.

npm init playwright@latest

One command. It installs browsers, generates a config, and creates a sample test. You are running your first test in under 5 minutes.

Winner: Playwright — lower barrier to entry, faster onboarding for new teams.

Round 2 ⚡ — Speed & Execution

This is where Playwright has a significant architectural advantage.

Playwright runs tests in parallel by default — across files AND within files if you configure it. It uses its own browser communication protocol which is fundamentally faster than WebDriver.

WDIO supports parallelism too, but it requires more configuration and the WebDriver protocol adds overhead per command. On large suites the difference becomes very noticeable.

In my experience running the same 300-test suite:

WDIO: ~18 minutes
Playwright: ~7 minutes

Same tests, same machine, same assertions. The speed difference is real and it matters when you are running tests on every pull request.

Winner: Playwright — faster out of the box, especially at scale.

Round 3 🔧 — Ecosystem & Flexibility

This is where WDIO fights back hard.

WDIO's plugin ecosystem is enormous. Need to test a mobile app? Add Appium service. Need visual regression? Add a plugin. Need to connect to Sauce Labs, BrowserStack, or LambdaTest? There is a service for everything.

// WDIO — adding Appium for mobile in the same framework
services: ['appium'],
capabilities: [{
  platformName: 'Android',
  'appium:deviceName': 'Pixel 4',
  'appium:app': './app/myapp.apk'
}]

WDIO is genuinely the better choice when your team needs to test web, mobile, and API from a single unified framework. That flexibility is hard to match.

Playwright supports mobile viewport emulation but does not support real device or native app testing natively. For pure web automation it is complete. For cross-platform teams it has gaps.

Winner: WDIO — unmatched flexibility across platforms and integrations.

Round 4 🐛 — Debugging Experience

Playwright's debugging tools are genuinely a joy to use.

# Run in headed mode with inspector
npx playwright test --debug

The Playwright Inspector lets you step through tests, inspect selectors, and see exactly what the browser is doing at each step. The trace viewer shows a full visual timeline of every action, screenshot, and network request — all in a beautiful UI.

// Playwright — built in tracing
await context.tracing.start({ screenshots: true, snapshots: true });
// ... run your test
await context.tracing.stop({ path: 'trace.zip' });

WDIO has decent debugging support but it relies more heavily on external tools and browser DevTools. The experience is functional but it does not match the polish of Playwright's built-in tooling.

Winner: Playwright — trace viewer alone makes debugging a completely different experience.

Round 5 📱 — Mobile & Cross-Platform Testing

No contest here.

WDIO with Appium is the industry standard for mobile automation. If your team tests iOS and Android alongside web, WDIO is the clear choice. The same framework, the same test patterns, the same reporting — just different capabilities.

Playwright announced experimental Android support but it is nowhere near production-ready for most teams. For mobile, WDIO is the mature, stable, battle-tested choice.

Winner: WDIO — mobile testing is its home turf.

Round 6 🧩 — Writing Tests Day to Day

Both tools write tests that feel natural. But there are meaningful differences in how they handle common scenarios.

Waiting for elements

// WDIO
await $('#submit-btn').waitForDisplayed({ timeout: 5000 });

// Playwright — auto-waiting built in, explicit when needed
await page.waitForSelector('#submit-btn', { state: 'visible' });

Playwright's auto-waiting is one of its most underrated features. It automatically waits for elements to be ready before acting on them. In WDIO you are more often managing waits manually.

Network interception

// Playwright — clean and built-in
await page.route('**/api/users', route => {
  route.fulfill({ json: { users: [] } });
});

// WDIO — requires additional setup and mock service

For API mocking and network interception, Playwright's built-in support is significantly cleaner.

Winner: Playwright — day-to-day ergonomics are smoother, especially for web-focused teams.

The Honest Summary

	WDIO	Playwright
Setup speed	Moderate	Fast
Execution speed	Good	Excellent
Mobile testing	Excellent	Limited
Debugging tools	Good	Excellent
Ecosystem	Enormous	Growing
Auto-waiting	Manual	Built-in
Cross-platform	Excellent	Web only
Learning curve	Steeper	Gentler

So Which Should You Choose?

Choose Playwright if:

Your team is web-only
You want fast onboarding and minimal config
Test execution speed is a priority
You value built-in debugging and tracing tools
You are starting a new project from scratch

Choose WDIO if:

You need web and mobile testing in one framework
Your project requires specific integrations (Appium, Sauce Labs, custom services)
You are working in an enterprise environment with existing WDIO infrastructure
Your team values configuration flexibility over convention

My Personal Take

If I am starting a new web automation project today, I reach for Playwright. The speed, the debugging tools, and the developer experience make it the right default for most web teams in 2026.

But if a client comes to me needing mobile and web automation unified under one framework, I am recommending WDIO without hesitation. It has earned that trust over a decade of production use.

The best tool is always the one that fits your team's actual needs — not the one winning Twitter debates this month.

Written by **Abdulfaizal Shaikh* — Senior Automation Engineer with 6+ years of hands-on experience building frameworks in both WebdriverIO and Playwright across fintech and product companies.*

How AI Is Changing QA — And What It Means for Automation Engineers

Faizal — Sat, 06 Jun 2026 07:29:25 +0000

Let me be honest with you.

When AI coding tools started getting good, I had a quiet moment of panic. I had spent years mastering test frameworks, building automation pipelines, writing page object models from scratch. And suddenly, a chatbot could generate a working Playwright test in 10 seconds.

So I did what most engineers do — I ignored the discomfort and kept working. But over the next few months, something shifted. Not in a scary way. In a way that actually made my job more interesting.

Here is what I have seen, lived, and learned about how AI is genuinely changing QA.

The Old World of QA Automation

Not long ago, a typical automation engineer's week looked like this:

Writing boilerplate selectors and page objects for hours
Manually analyzing test failure logs one by one
Spending half a sprint on test data setup
Writing the same API assertion patterns over and over

It was valuable work. But a lot of it was mechanical. The kind of work where experience helped you go faster, but the ceiling was always your own typing speed and mental bandwidth.

That world is changing fast.

What AI Is Actually Doing to QA Right Now

1. 🤖 Generating Test Boilerplate Instantly

The most immediate change is speed. Tools like GitHub Copilot, Cursor, and even ChatGPT can generate a full page object, a set of API tests, or a data-driven test suite in seconds.

Does it always get it right? No. Does it save 40% of the time on setup tasks? Absolutely yes.

The engineers who resist this are like developers who refused to use Stack Overflow in 2012. The tool is not the threat — falling behind on how to use it is.

2. 🔍 Smarter Test Failure Analysis

This one is underrated. AI-powered test observability tools can now:

Cluster similar failures automatically
Identify root causes across hundreds of test runs
Distinguish flaky failures from real regressions without human review

What used to take a senior engineer 2 hours of log diving now takes minutes. This is not replacing QA thinking — it is removing the most tedious part of it.

3. 🧠 Exploratory Testing Augmentation

AI is starting to assist with exploratory testing in ways nobody expected. Tools can now crawl your app, learn user flows, and suggest edge cases that human testers miss.

I recently saw a tool flag a race condition in a checkout flow that had existed for two years undetected. No human had thought to test that specific timing scenario. The AI found it in a crawl session.

4. 📝 Test Case Generation From Requirements

Feed a user story into a modern AI tool and it will output a set of test cases — happy path, negative path, edge cases — in seconds. Not perfect. But a genuinely useful first draft that a QA engineer can review and refine in minutes instead of hours.

This is shifting the QA role from writer to reviewer and strategist. That is a promotion, not a demotion.

5. 🔧 Self-Healing Locators

One of the biggest time sinks in UI automation has always been broken selectors. A developer renames a class, moves a button, and suddenly 50 tests are failing for the wrong reason.

AI-powered frameworks now offer self-healing locators that detect when a selector breaks and automatically find the closest matching element. Tools like Healenium and built-in features in modern platforms are making flaky UI tests a smaller problem than they used to be.

What AI Cannot Do (Yet)

Let us be clear-eyed about the limits.

AI cannot understand business context. It does not know that your checkout flow is used by 2 million users daily and a 200ms regression matters more than a broken tooltip. You do.

AI cannot own quality. It can flag, suggest, generate, and analyze. But the decision of what is good enough to ship — that judgment still belongs to a human who understands the product, the users, and the risk.

AI cannot build a quality culture. Getting developers to care about testing, running effective bug triage meetings, pushing back on impossible deadlines — none of that is automatable.

AI hallucinates. Generated tests can look correct and be completely wrong. An AI will confidently write an assertion that tests nothing meaningful. You still need the expertise to catch that.

What This Means for Your Career as a QA Engineer

Here is the uncomfortable truth: the QA engineers who will struggle are the ones whose entire value is writing test scripts manually. Because that specific skill is getting commoditized.

But the QA engineers who will thrive are those who use AI to go 10x faster on the mechanical work — and spend the freed-up time on the things that actually require a human:

Test strategy — deciding what to test and why
Risk analysis — understanding which failures actually matter
Quality advocacy — making the whole team care about quality
Framework architecture — designing systems that scale
Exploratory thinking — finding the bugs nobody thought to look for

AI is compressing the distance between a junior and mid-level engineer on scripting tasks. But it is widening the gap between engineers who think about quality deeply and those who do not.

How I Am Using AI in My QA Work Today

To make this concrete, here is how AI has changed my actual workflow:

I use Copilot to generate the first draft of any new page object or API test class. I review, refactor, and own the final result.
I use AI chat tools to analyze stack traces and suggest root causes when I am debugging a complex failure chain.
I use AI to generate edge case test ideas from acceptance criteria before I start writing any automation.
I still write critical test logic by hand. The parts that touch business-critical flows, I want to fully understand and own.

The pattern is consistent: AI handles the repetitive, I handle the strategic.

The Mindset Shift That Matters Most

Stop asking "will AI replace QA engineers?"

Start asking "what kind of QA engineer will be irreplaceable when AI handles the repetitive parts?"

The answer is clear. Engineers who think critically about quality, who communicate risk to stakeholders, who design systems rather than just scripts, who understand the product as deeply as any developer — those engineers are not going anywhere.

If anything, AI is creating more room for QA engineers to do the work that actually matters. The work that requires judgment, creativity, and accountability.

The engineers who embrace that shift will not just survive the AI wave — they will ride it.

Written by **Abdulfaizal Shaikh* — Senior Automation Engineer with 7+ years of experience in UI, API, and mobile test automation. Currently exploring how AI tooling integrates with modern QA practices.*

Common Mistakes Senior QA Engineers Make (And How to Fix Them)

Faizal — Sat, 06 Jun 2026 07:04:17 +0000

After 6+ years in QA automation — working across fintech, product startups, and enterprise software — I've seen the same patterns play out again and again. Not in junior engineers. In senior ones.

These are the mistakes that slow teams down, kill confidence in test suites, and make automation feel like a burden instead of a superpower. I've made most of them myself. Here's what I wish someone had told me earlier.

Mistake 1 🏗️ — Writing Tests Without a Strategy

Most engineers jump straight into writing test scripts without thinking about what to automate, why, and at which layer. The result? Thousands of flaky E2E tests covering things already validated by unit tests — and zero coverage on business-critical paths that actually matter.

Classic symptom: Your test suite takes 45 minutes to run and the team has stopped trusting it.

The Fix:
Apply the Test Pyramid — more unit tests at the base, fewer E2E tests at the top. Map every test to a user story or business risk. If you can't answer "what breaks if this test fails?", don't automate it yet.

Mistake 2 😴 — Ignoring Test Maintenance Until It's Too Late

Automation is not "write once, forget forever." I've seen teams where 30% of tests are permanently skipped because "we'll fix them later." Later never comes. The suite rots, trust collapses, and someone suggests scrapping everything and starting over.

The Fix:
Treat tests like production code. Add a flaky test threshold policy — if a test fails 3 times in a row with no code change, it gets quarantined and triaged immediately. Schedule a monthly "test debt" cleanup session.

Mistake 3 🔗 — Hardcoding Data, URLs & Credentials

You'd be surprised how often I see test files with hardcoded environment URLs, test user credentials, or even database connection strings baked directly into the code. This makes tests impossible to run across environments and is a serious security risk.

// ❌ Bad — hardcoded everywhere
const baseUrl = "https://staging.myapp.com";
const password = "Test@1234";

// ✅ Good — from environment config
const baseUrl = process.env.BASE_URL;
const password = process.env.TEST_PASSWORD;

✅ The Fix

Use .env files and a config layer. Never commit credentials to git. Use secret managers (GitHub Secrets, AWS Secrets Manager) in your CI/CD pipelines.

// ❌ Bad — hardcoded everywhere
const baseUrl = "https://staging.myapp.com";
const password = "Test@1234";

// ✅ Good — pulled from environment
const baseUrl = process.env.BASE_URL;
const password = process.env.TEST_PASSWORD;

Mistake 4 ⏰ — Using Thread.sleep() Instead of Smart Waits

Static sleeps are the silent killer of automation suites. They make tests slow on fast machines and flaky on slow ones. Even experienced engineers fall into this trap when debugging locally and forgetting to clean up.

🚨 Real impact: A suite with 200 tests each having a 2-second sleep adds 6+ minutes of pure wasted time per run.

✅ The Fix

Always use explicit waits — wait for a specific element state, network idle, or API response.

//Bad approach:
await page.waitForTimeout(3000);

//Good approach in Playwright:
await page.waitForSelector('#submit-btn', { state: 'visible' });

//Good approach in WDIO:
await $('#submit-btn').waitForDisplayed({ timeout: 5000 });

Mistake 5 📊 — Not Measuring Test Coverage or Quality

Having 500 automated tests means nothing if they all test the same login flow 500 different ways. Senior engineers often assume "more tests = better coverage." Without metrics, you're flying blind.

✅ The Fix

Track these as KPIs every sprint:

Code coverage % — use Istanbul for JS, JaCoCo for Java
Feature coverage — maintain a traceability matrix mapping tests to requirements
Flakiness rate — aim to keep it below 2%
Average test run time — flag any single test taking over 30 seconds

Mistake 6 🤐 — Treating QA as a Gatekeeper, Not a Partner

The biggest non-technical mistake on this list. Senior QA engineers who position themselves as the "final blocker before release" create friction, resentment, and an us-vs-them culture. Quality is everyone's responsibility, not a single department's job.

✅ The Fix

Shift to a quality coaching mindset. Get involved early — in sprint planning, design discussions, and code reviews. Help developers write testable code from the beginning. Quality built-in beats quality bolted-on every single time.

DEV Community: Faizal

10 Playwright Tips That Will Change How You Write Tests

Tip 1 🎯 — Stop Using waitForTimeout. Seriously.

Tip 2 🔍 — Use getByRole Over CSS Selectors

Tip 3 🏗️ — Use Page Object Model But Keep It Lean

Tip 4 🌐 — Mock Your APIs for Faster, Stable Tests

Tip 5 📸 — Use Trace Viewer When Tests Fail in CI

Tip 6 ⚙️ — Use test.describe and test.use for Context Isolation

Tip 7 🔐 — Save Authentication State and Reuse It

Tip 8 🧪 — Use expect Soft Assertions for Multi-Step Validations

Tip 9 📊 — Tag Your Tests and Run Subsets Smartly

Tip 10 🛠️ — Use codegen to Bootstrap Tests, Not to Write Them

Wrapping Up

WDIO vs Playwright — An Honest Comparison from Someone Who Has Used Both

A Quick Introduction for Context

Round 1 🚀 — Getting Started

WDIO

Playwright

Round 2 ⚡ — Speed & Execution

Round 3 🔧 — Ecosystem & Flexibility

Round 4 🐛 — Debugging Experience

Round 5 📱 — Mobile & Cross-Platform Testing

Round 6 🧩 — Writing Tests Day to Day

Waiting for elements

Network interception

The Honest Summary

So Which Should You Choose?

My Personal Take

How AI Is Changing QA — And What It Means for Automation Engineers

The Old World of QA Automation

What AI Is Actually Doing to QA Right Now

1. 🤖 Generating Test Boilerplate Instantly

2. 🔍 Smarter Test Failure Analysis

3. 🧠 Exploratory Testing Augmentation

4. 📝 Test Case Generation From Requirements

5. 🔧 Self-Healing Locators

What AI Cannot Do (Yet)

What This Means for Your Career as a QA Engineer

How I Am Using AI in My QA Work Today

The Mindset Shift That Matters Most

Common Mistakes Senior QA Engineers Make (And How to Fix Them)

Mistake 1 🏗️ — Writing Tests Without a Strategy

Mistake 2 😴 — Ignoring Test Maintenance Until It's Too Late

Mistake 3 🔗 — Hardcoding Data, URLs & Credentials

✅ The Fix

Mistake 4 ⏰ — Using Thread.sleep() Instead of Smart Waits

✅ The Fix

Mistake 5 📊 — Not Measuring Test Coverage or Quality

✅ The Fix

Mistake 6 🤐 — Treating QA as a Gatekeeper, Not a Partner

✅ The Fix

Tip 1 🎯 — Stop Using `waitForTimeout`. Seriously.

Tip 2 🔍 — Use `getByRole` Over CSS Selectors

Tip 6 ⚙️ — Use `test.describe` and `test.use` for Context Isolation

Tip 8 🧪 — Use `expect` Soft Assertions for Multi-Step Validations

Tip 10 🛠️ — Use `codegen` to Bootstrap Tests, Not to Write Them