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

30. How would you handle an animation or loading spinner?

I would understand what indicates that the page is ready.

For example:

Spinner visible
      ↓
API completes
      ↓
Spinner disappears
      ↓
Content becomes available

I would synchronize with the application’s meaningful state rather than simply waiting for an arbitrary amount of time.

---

31. How would you identify the exact step where a test failed?

I would use:

• Clear test step structure
• Meaningful assertions
• Screenshots
• Trace
• Video when configured
• Test reports
• Logging where useful

A good automation framework should make failures easy to understand.

The goal is:

Failure should tell the team what went wrong, not simply say “test failed.”

---

32. How would you debug a flaky Playwright test?

I would first determine whether the flakiness is caused by:

• Application timing
• Test data
• Locator instability
• Shared state
• Network
• Parallel execution
• Environment differences

Then I would reproduce the failure and inspect traces or artifacts.

I would avoid hiding the problem by simply increasing retries.

Important Interview Point

Retrying a flaky test is not the same as fixing the flakiness.

---

33. How would you use screenshots and videos during failure investigation?

Screenshots help me understand the UI state at failure.

Video can show the sequence of actions leading to failure.

I would use these artifacts especially in CI because I may not have direct access to the failing machine.

For difficult failures, tracing can provide even more useful information.

---

34. How would you investigate a test that passes individually but fails in the complete suite?

This is a very important real-world scenario.

I would suspect:

• Shared test data
• Test dependency
• Browser state
• Storage state
• Parallel execution
• Database state
• Ordering dependency

I would run the failing test with related tests and inspect whether another test is modifying shared state.

Strong Answer

“A test should ideally be independent of execution order.”

---

35. How would you organize smoke, regression, and sanity tests?

I would categorize tests using tags or projects according to the framework design.

For example:

Smoke
  → Critical login
  → Main navigation
  → Core business flow

Regression
  → Full functional coverage

Sanity
  → Focused validation after a specific change

Then CI can run the appropriate suite depending on the pipeline stage.

---

36. How would you run only a particular group of tests?

I would use Playwright’s test selection capabilities, such as:

• Test file
• Test title
• Tags/annotations
• Project
• Directory

For example, teams can create a smoke-tagged suite and run that suite during fast validation.

---

37. How would you run tests on different browsers?

Playwright supports multiple browser engines.

I would configure projects for the browsers required by the product.

For example:

Chromium
Firefox
WebKit

I would not necessarily run every test on every browser if the project’s risk and coverage strategy does not require it.

---

38. How would you handle browser-specific failures?

First, I would reproduce the failure only on the affected browser.

Then I would determine whether it is:

• Application compatibility issue
• Browser-specific behavior
• Locator issue
• Timing issue
• Test implementation problem

If the product genuinely behaves differently on one browser, I would raise it as a compatibility defect when appropriate.

---

39. How would you run Playwright tests in parallel safely?

Parallel execution can reduce execution time, but tests need to be designed for isolation.

I would ensure:

• Independent test data
• No shared mutable state
• Unique records
• Safe authentication strategy
• Database isolation where required

The goal is not simply to turn on maximum parallelism.

---

40. What problems can parallel execution create?

Parallel execution can expose hidden dependencies.

For example:

Test A → updates Customer 101
Test B → deletes Customer 101

If both execute simultaneously, either test may fail.

Other problems include:

• Shared accounts
• Shared files
• Shared database records
• Port conflicts
• Resource limits

So parallel execution requires good test design.

---

Pages: 1 2 3 4 5 6