50 Playwright Interview Questions: Powerful Answers to Boost Your QA Career

Playwright Interview Questions are not only about knowing commands. Interviewers want to know how you think, how you design automation, and how you handle real project problems.

If you are preparing for Playwright Interview Questions, this guide explains 50 practical and scenario-based questions in simple language so you can confidently explain your answers during an interview.

Instead of memorizing complicated definitions, try to understand the reason behind each Playwright concept.

---

Playwright Interview Questions: Practical Scenarios

1. How would you decide whether a test case should be automated using Playwright?

Simple Answer

I would not automate every test case.

First, I would identify scenarios that are:

• Repeated frequently
• Stable enough to automate
• Time-consuming manually
• Important for regression
• Data-driven
• Required across multiple browsers

For example, login, checkout, search, and critical business workflows are usually good automation candidates.

Interview Tip

Don’t say:

“I automate everything.”

A better answer is:

“I prioritize automation based on execution frequency, business importance, stability, and maintenance effort.”

---

2. What would you check before selecting a locator?

Simple Answer

I first look for a locator that is:

1. Unique
2. Stable
3. Easy to understand
4. Closely connected to the user’s interaction

For example, if the application provides a reliable test ID, I would prefer it over a long XPath.

Example

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

The important thing is not memorizing locator methods. The important thing is choosing a locator that is unlikely to break.

If you want to explore Playwright’s locator capabilities in more detail, check the .official Playwright documentation on locators.

---

3. What would you do when a locator works today but may break after UI changes?

I would discuss the locator with the development team and try to use a stable attribute or semantic locator.

For example, instead of:

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

I would prefer something meaningful such as:

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

or a stable test attribute.

Interview Point

A good automation engineer thinks about future maintenance, not just making today’s test pass.

---

4. How would you automate a page where the same button appears multiple times?

First, I would understand whether the buttons represent different actions.

If they have different accessible names, I would identify them using those names.

If they are genuinely identical, I would scope the locator to the correct section of the page.

Example

const productCard = page.getByRole('article').filter({
  hasText: 'Laptop'
});

await productCard.getByRole('button', { name: 'Add to Cart' }).click();

This is better than blindly using:

page.getByRole('button').nth(3)

because the order may change.

---

5. How do you handle an element whose text keeps changing?

I would avoid depending on the complete dynamic text.

For example, if the message changes from:

Order 12345 created

to:

Order 12346 created

I can validate the stable part.

await expect(page.getByText(/Order \d+ created/)).toBeVisible();

The idea is to automate the business rule, not the changing value.

---

6. What would you do if an element is visible but Playwright still cannot click it?

I would not immediately add a force click.

First, I would investigate:

• Is another element covering it?
• Is an animation still running?
• Is the element actually enabled?
• Is the page still loading?
• Is the locator pointing to the correct element?

Playwright performs actionability checks before actions.

Only after understanding the actual problem would I decide whether a different approach is required.

---

7. How would you investigate a test that passes locally but fails in CI?

I would compare the environments.

I would check:

• Browser version
• Operating system
• Environment URL
• Test data
• Credentials
• Timing
• Network behavior
• Parallel execution
• Screenshots
• Trace
• Test report

I would first reproduce the CI conditions as closely as possible instead of randomly changing waits.

Strong Interview Answer

“I treat CI failures as an environment or synchronization investigation rather than immediately assuming the application is defective.”

---

8. How would you decide whether a failure is a product bug or automation issue?

I would reproduce the same scenario manually.

Then I would check:

1. Test input
2. Locator
3. Application behavior
4. Network/API response
5. Console errors
6. Screenshot or trace

If the application behaves incorrectly with valid manual steps, it could be a product defect.

If the application works correctly but the test interacts incorrectly, it is likely an automation issue.

---

9. How would you structure a Playwright project for a growing team?

I would keep responsibilities separated.

For example:

tests/
pages/
fixtures/
utils/
test-data/
config/
api/

The exact structure depends on the project, but my goal would be:

• Tests should describe business scenarios
• Page objects should handle page interactions
• Fixtures should manage reusable setup
• Utilities should contain genuinely reusable helpers
• Test data should be separated from test logic

This makes the framework easier for multiple QA engineers to maintain.

---

10. What would you keep inside a Page Object and what would you keep inside a test?

A Page Object should contain page-specific interaction logic.

For example:

async login(username: string, password: string) {
  await this.username.fill(username);
  await this.password.fill(password);
  await this.loginButton.click();
}

The test should describe the business scenario.

await loginPage.login(user.email, user.password);

await expect(dashboardPage.heading).toBeVisible();

Simple Rule

Page Object = How

Test = What and Why

---

Pages: 1 2 3 4 5 6