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

21. How would you handle an iframe in Playwright?

I would use Playwright’s frame-related capabilities rather than treating iframe elements like normal page elements.

For example:

const paymentFrame = page.frameLocator('#payment-frame');

await paymentFrame.getByLabel('Card Number').fill('...');

The important concept is:

The iframe has its own document context.

---

22. How would you test a page containing multiple iframes?

I would identify each iframe separately and scope the interactions to the correct frame.

I would avoid generic locators that could accidentally interact with the wrong frame.

This becomes especially important in payment, authentication, advertising, and embedded-widget scenarios.

---

23. What would you do if an API response is required before continuing the UI test?

I would monitor the expected network request instead of using an arbitrary delay.

For example:

const responsePromise = page.waitForResponse(
  response => response.url().includes('/orders') &&
              response.request().method() === 'GET'
);

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

const response = await responsePromise;

expect(response.ok()).toBeTruthy();

This synchronizes the test with an actual application event.

---

24. How would you verify that the UI displayed data returned by an API?

I would compare the API response with what is displayed on the UI.

For example:

API → Customer Name = "Mrunal"
UI → Customer Name = "Mrunal"

This helps validate not only the API but also the UI-to-API integration.

---

25. How would you mock an API when the backend is unavailable?

I would use Playwright’s network interception capabilities.

The idea is:

UI Request
     ↓
Intercept
     ↓
Mock Response
     ↓
UI processes response

This allows me to test UI behavior without depending on the actual backend.

It is especially useful for:

• Error responses
• Empty responses
• Slow responses
• Rare backend conditions

---

26. When would you use API testing instead of UI testing?

If I need to validate business logic at the API level, API testing is usually faster and more direct.

For example:

Create Customer API
Update Customer API
Delete Customer API

I would not necessarily create a complete UI test for every API scenario.

A balanced automation strategy uses:

API tests for backend validation

UI tests for critical user journeys

---

27. How would you wait for a specific backend response?

I would wait for the expected response rather than using:

await page.waitForTimeout(5000);

I would identify the request using:

• URL
• HTTP method
• Response status
• Response characteristics

This makes the test more deterministic.

---

28. How would you troubleshoot a test that is failing because of timing?

First, I would identify what the test is waiting for.

For example:

Click Login
      ↓
API request
      ↓
Dashboard loads
      ↓
User profile appears

Instead of adding:

waitForTimeout(5000)

I would synchronize with the required UI or network condition.

---

29. Why would you avoid adding fixed waits everywhere?

Because fixed waits make tests:

• Slower
• Less reliable
• Difficult to maintain

Suppose the application becomes ready in 500 ms.

If I use:

waitForTimeout(5000)

I waste 4.5 seconds.

If the application takes 6 seconds, the same wait may still fail.

So I prefer condition-based synchronization.

---

Pages: 1 2 3 4 5 6