10 Playwright Mistakes Beginners Make — And How to Avoid Them

The Playwright mistakes beginners make can often be avoided by following a few simple automation principles.

You learned Playwright. You can open a browser, click a button, enter text, and run a test.

But then something happens…

1. Your test passes on your laptop but fails in CI.
2. Your locator suddenly stops working.
3. You add waitForTimeout() everywhere.
4. Tests become slow and flaky.
5. One small UI change breaks multiple tests.

Sound familiar?

If you’re a beginner in Playwright with TypeScript, you may encounter several Playwright mistakes beginners make while creating your first automation tests.

The good news?

1. Most Playwright failures aren’t because Playwright is difficult.
2. They’re usually caused by how we’re writing the tests.

In this article, let’s look at 10 common Playwright mistakes beginners make, why they happen, and what you should do instead.

These Playwright mistakes beginners make are especially common when you’re moving from manual testing to automation.

---

Before We Start

Think about this:

A good automation test isn’t just a test that passes. It’s a test that remains reliable when the application changes.

That’s the mindset you should develop from day one.

---

Mistake 1: Playwright Mistakes Beginners Make — Using waitForTimeout() Everywhere

This is probably one of the most common beginner mistakes.

You write:

await page.waitForTimeout(3000);
await page.click('#login');

The test works.

So you think:

“Great! I’ll just add another wait.”

And suddenly your framework contains:

waitForTimeout(1000)
waitForTimeout(2000)
waitForTimeout(5000)
waitForTimeout(3000)

Why is this a problem?

You’re waiting for a fixed amount of time instead of waiting for the actual condition.

If the application is ready in 500 ms, you’re still waiting.

If the application takes 4 seconds, your 3-second wait may not be enough.

Better approach

Use Playwright’s built-in waiting and assertions.

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

await expect(page.getByText('Welcome')).toBeVisible();

QA Tip

Don’t ask: “How many seconds should I wait?”

Ask:

“What condition tells me the application is ready?”

That’s a much better automation mindset.

Playwright provides built-in auto-waiting , which helps tests wait for elements to become actionable instead of relying on fixed delays.

---

Mistake 2: Using Weak Locators

Beginners often choose locators based on whatever is easiest to find.

For example:

await page.locator('div:nth-child(3)').click();

Or:

await page.locator('.btn-primary').click();

These might work today.

But what happens when the developer changes the HTML?

Your test breaks.

Avoid overly fragile selectors

page.locator('div > div > button:nth-child(2)')

Prefer user-facing or stable locators

page.getByRole('button', { name: 'Login' })

or:

page.getByLabel('Email')

or:

page.getByTestId('login-button')

QA Tip

When selecting a locator, ask:

“Would this locator survive a UI redesign?”

If the answer is no, reconsider it.

For a deeper understanding of Playwright’s locator strategy, check the official Playwright Locator documentation

---

Mistake 3: Using the Same Locator for Multiple Elements

Imagine a page contains:

Delete
Delete
Delete
Delete

A beginner may write:

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

But which Delete button are you clicking?

Make the locator more specific

await page
  .getByRole('row', { name: 'Mrunal QA Engineer' })
  .getByRole('button', { name: 'Delete' })
  .click();

Now your test communicates the business intent:

Find Mrunal’s row → click Delete.

Remember

Good locators don’t just find elements.

They explain what your test is trying to do.

---

Pages: 1 2 3 4 5