Playwright Scenario Questions: Flaky Tests, Jenkins & Multi-User

Your Test Is Failing Randomly – How Do You Debug?

Random failures generally indicate flaky tests rather than application defects.

A structured debugging approach helps identify the actual root cause.

Interview Answer

"If a test fails randomly, I first treat it as a flaky test. I investigate synchronization issues, dynamic elements, test data dependency, environment instability, and overall test design. I reproduce the issue, analyze logs, screenshots, and traces, identify the root cause, and then stabilize the automation."

Advertisement

Debugging Approach

• Identify whether the failure is truly random.
• Check if it occurs:
  • Only in CI/CD.
  • Only during parallel execution.
  • Only occasionally.
• Review:
  • Execution logs.
  • Screenshots.
  • Videos.
  • Playwright Trace.
• Fix the underlying problem instead of simply retrying the test.

The collected debugging evidence helps determine whether the problem is caused by:

• Timing issues
• Environment differences
• Test data
• Application defects

Element Is Visible but the Click Is Failing

Sometimes an element appears visible on the page but cannot be clicked successfully.

Visibility alone does not guarantee clickability.

Interview Answer

"An element may be visible but still not clickable because of overlays, loaders, animations, disabled state, or another element intercepting the click. Although Playwright performs auto-waiting, the click can still fail if the element is not stable. We solve this by waiting until the element is enabled and stable, removing overlays, and using proper waits and assertions."

Common Reasons

• Overlay covering the element.
• Loading spinner.
• Page animation.
• Disabled button.
• Another element intercepting the click.

Important Point

An element must be:

• Visible
• Enabled
• Stable
• Not blocked by another element

before it can be clicked successfully.

Tests Pass Locally but Fail in Jenkins

This is one of the most common interview scenarios.

Interview Answer

"When tests pass locally but fail in Jenkins, the most common reason is environment differences. These include headless execution, slower machines, browser version differences, missing environment variables, test data issues, or synchronization problems. Jenkins executes tests in a different environment, so tests must be environment-independent."

Common Causes

• Headless browser execution.
• Performance differences.
• Browser version mismatch.
• Missing environment variables.
• Different test data.
• Synchronization issues.

Solution

• Use proper synchronization.
• Avoid environment-dependent logic.
• Configure environment variables correctly.
• Capture traces, screenshots, and logs for CI failures.

Handling Dynamic Elements

Modern web applications built using frameworks like React or Angular frequently generate dynamic elements.

These elements may change:

• IDs
• Text
• Indexes
• DOM structure

Interview Answer

"Dynamic elements frequently change their IDs or text. In Playwright, I handle them using stable locators such as data-testid, role-based locators, and text-based locators. I avoid absolute XPath and dynamic IDs."

Best Practices

• Prefer data-testid.
• Use role-based locators.
• Use text-based locators.
• Avoid absolute XPath.
• Avoid dynamic IDs.

Handling CAPTCHA

CAPTCHA is specifically designed to prevent automation.

It should not be automated directly.

Interview Answer

"We handle CAPTCHA by disabling it in test environments, using feature flags, authenticating through backend APIs, or mocking CAPTCHA validation."

Common Approaches

• Disable CAPTCHA in QA.
• Use feature flags.
• Login through backend APIs.
• Mock CAPTCHA validation.

Production environments continue using real CAPTCHA protection.

Testing Notifications

Notifications provide feedback after user actions.

Examples include:

• Success messages.
• Error messages.
• Warning messages.
• Information messages.

Interview Answer

"In Playwright, notification testing involves validating the visibility, text, and behavior of toast messages, alerts, or browser notifications."

Validation Points

• Notification appears.
• Correct message is displayed.
• Notification behaves correctly.
• Auto-dismiss functionality works as expected.

Cross-Browser Scenarios

Cross-browser testing verifies that an application behaves consistently across different browsers.

Playwright makes this easy by running the same automation across multiple browser engines.

Browsers Supported

• Chromium
• Firefox
• WebKit

Benefits

• Detect browser-specific issues.
• Verify consistent application behavior.
• Execute tests across browsers using the same automation scripts.

Multi-User Scenarios

Playwright supports multi-user testing using separate browser contexts.

Each browser context behaves like an independent browser session.

Interview Answer

"In Playwright, multi-user testing is handled using separate browser contexts or separate authentication states. Each browser context behaves like an independent browser, so cookies and sessions remain isolated."

Common Scenario

One browser context:

• Administrator

Second browser context:

• Normal User

Both users perform actions independently without sharing sessions or cookies.

Benefits

• Session isolation.
• Independent authentication.
• Realistic multi-user workflows.

File Download Validation

File download validation ensures that the expected file is downloaded correctly after user interaction.

A common example is downloading invoices or reports.

Download Process

Playwright waits for the download event before validating the file.

Methods Used

Wait for Download Event

waitForEvent('download')

Retrieve the Suggested Filename

suggestedFilename()

Save the Downloaded File

saveAs()

Validation Steps

• Verify the download occurred.
• Verify the filename.
• Save the file.
• Validate file contents if required.

Test Data Cleanup

Test data cleanup means removing or resetting all data created during test execution.

This ensures that every test starts with a clean environment.

Interview Answer

"I perform test data cleanup using APIs, database cleanup, and teardown hooks so every test executes independently. I usually prefer API-based cleanup because it is faster and more reliable."

Common Cleanup Methods

• API cleanup
• Database cleanup
• Teardown hooks

Hook Used

test.afterEach()

Benefits

• Independent tests.
• Stable automation.
• Reduced flaky failures.
• Clean execution environment.

FAQs

How do you debug a randomly failing test?

Treat it as a flaky test.

Check:

• Synchronization
• Dynamic elements
• Test data
• Environment
• Test design

Then analyze logs, screenshots, videos, and traces to identify the root cause.

Why does a click fail even when an element is visible?

Visibility alone is not sufficient.

The element may be:

• Covered by an overlay.
• Disabled.
• Still animating.
• Intercepted by another element.

Wait until the element is enabled, stable, and unobstructed.

Why do tests pass locally but fail in Jenkins?

Common reasons include:

• Headless execution
• Environment differences
• Browser versions
• Missing environment variables
• Test data differences
• Timing issues

How do you handle CAPTCHA?

Never automate CAPTCHA directly.

Instead:

• Disable it in QA.
• Use feature flags.
• Authenticate through APIs.
• Mock CAPTCHA validation.

How do you test multi-user scenarios?

Create separate browser contexts.

Each context maintains its own:

• Cookies
• Authentication
• Session

Example:

• Admin Context
• User Context

How do you validate file downloads?

• Wait for the download event.
• Validate the filename using suggestedFilename().
• Save the file using saveAs().
• Verify file contents if required.

How do you clean up test data?

Use:

• APIs
• Database cleanup
• test.afterEach() teardown hooks

This keeps every test independent and stable.