Crack Playwright Java Interviews

1. Selenium Grid

Part I - Core Questions

Question 1.5

What are the limitations of using Selenium Grid with Playwright compared to native Playwright execution?

Interview-Style Answer

Using Selenium Grid with Playwright has several limitations compared to native Playwright execution because it introduces an external infrastructure layer (Selenium Grid) and relies on CDP-based attachment instead of Playwright’s native browser control model.

Native Playwright execution is simpler, faster, and fully integrated with Playwright’s architecture, while Selenium Grid adds complexity and reduces some of Playwright’s built-in advantages.

Detailed Explanation

Native Playwright execution:

Browser browser = playwright.chromium().launch();
Page page = browser.newPage();

This model is fully managed by Playwright:

• Browser lifecycle
• Context isolation
• Network handling
• Auto-waiting integration
• Tracing, screenshots, video

Selenium Grid execution introduces an external dependency:

SELENIUM_REMOTE_URL=http://<selenium-hub-ip>:4444 mvn test

Here Playwright must rely on Selenium Grid to:

• Start the browser session
• Expose CDP endpoint
• Manage remote execution

Key limitations of Selenium Grid + Playwright

1. Experimental support in Playwright ecosystem
2. Dependency on Selenium Grid infrastructure stability
3. Only Chromium-based browsers are realistically supported
4. Additional network latency due to remote execution
5. More complex debugging across multiple layers
6. Harder root cause analysis (Playwright vs Grid vs Node vs CDP)
7. Version compatibility challenges (Grid, browser, CDP, Playwright)
8. Not aligned with Playwright’s native execution model
9. Reduced simplicity compared to local/Playwright-managed execution
10. Operational overhead (Grid setup, scaling, maintenance)

Debugging complexity difference

Native Playwright:

Test → Playwright → Browser

Selenium Grid + Playwright:

Test → Playwright → Selenium Grid Hub → Node → Browser → CDP → Back to Playwright

Each extra layer increases failure points:

- Grid routing issues
- Node registration issues
- CDP connection failures
- Network/firewall issues
- Container/Docker misconfigurations

When native Playwright is better

Native execution is preferred for:

• CI/CD pipelines
• Parallel execution (workers/sharding)
• Cross-browser testing (Chromium, Firefox, WebKit)
• Trace Viewer + debugging workflows
• Stable automation frameworks

Common Mistake

A common mistake is assuming Selenium Grid integration provides the same performance, simplicity, and reliability as native Playwright execution. In reality, it introduces additional infrastructure dependencies and complexity, and should only be used when there is a strong requirement to reuse existing Selenium Grid infrastructure.

Question 1.8

How would you design a Playwright Java framework to optionally run tests locally or on Selenium Grid?

Interview-Style Answer

I would design the framework so that local execution is the default mode, and Selenium Grid execution is enabled through external configuration.

The test code should remain completely unchanged. The framework layer should decide whether to run locally or on Selenium Grid based on environment variables or configuration properties such as RUN_MODE and SELENIUM_REMOTE_URL.

Detailed Explanation

A clean Playwright framework must separate test logic from execution strategy.

Configuration example:

RUN_MODE=local
RUN_MODE=grid
SELENIUM_REMOTE_URL=http://localhost:4444
BROWSER=chromium

Framework decision flow

1. Read execution mode from configuration
2. If RUN_MODE = local → launch browser locally
3. If RUN_MODE = grid → validate SELENIUM_REMOTE_URL
4. Ensure Grid supports required browser (Chrome/Edge only)
5. Create browser using Playwright API consistently
6. Keep all test classes independent of execution mode

Example framework bootstrap logic

String runMode = System.getenv().getOrDefault("RUN_MODE", "local");

if ("grid".equalsIgnoreCase(runMode)) {
    String gridUrl = System.getenv("SELENIUM_REMOTE_URL");

    if (gridUrl == null || gridUrl.isBlank()) {
        throw new RuntimeException("SELENIUM_REMOTE_URL is required for Grid execution");
    }
}

Browser browser = playwright.chromium().launch();
Page page = browser.newPage();

When Grid is enabled, the underlying execution is routed through Selenium Grid automatically, while the test code remains unchanged.

Test code (must stay identical for both modes)

page.navigate("https://example.com");

page.getByRole(AriaRole.BUTTON).click();

Recommended framework design practices

1. Keep execution configuration outside test classes
2. Centralize browser creation in a factory layer
3. Fail fast if Grid configuration is missing or invalid
4. Log execution mode at startup (local vs grid)
5. Keep local mode as default for developer productivity
6. Restrict Grid usage to Chrome/Edge compatibility
7. Capture trace, screenshots, and videos uniformly for both modes
8. Document Selenium Grid support as experimental in framework README

Common Mistake

A common mistake is introducing separate test logic or branching inside test cases for local vs Grid execution. A well-designed framework should only change the execution layer, not the test behavior, ensuring consistency across environments.

2. Snapshot testing

Part I - Core Questions

Question 2.3

When is snapshot testing not suitable?

Interview-Style Answer

Snapshot testing is not suitable when the output is highly dynamic, changes frequently, or contains values that are expected to vary between test runs.

Examples include timestamps, random IDs, notification counts, live prices, search results, personalized recommendations, and rapidly changing dashboard data. In these situations, snapshots often produce noisy failures that do not represent real regressions.

For such scenarios, fine-grained assertions, partial matching, or regular expressions are usually better choices.

Detailed Explanation

Snapshot testing works best when the captured structure is stable and meaningful over time.

Example:

PlaywrightAssertions.assertThat(page.locator("main"))
    .matchesAriaSnapshot("""
        - heading "Checkout"
        - textbox "Name"
        - textbox "Email"
        - button "Pay now"
    """);

This is a good candidate because the checkout page structure is expected to remain relatively stable.

However, snapshot testing becomes less effective when the content naturally changes between executions.

Common examples include:

- timestamps and dates
- random IDs
- order numbers
- session identifiers
- notification counts
- live prices
- stock values
- search results
- personalized recommendations
- frequently changing dashboards

For example:

PlaywrightAssertions.assertThat(page.locator("main"))
    .matchesAriaSnapshot("""
        - heading "Dashboard"
        - text: Last updated at 10:45:21
        - text: Notifications 17
        - text: Recommended job: Java Automation Engineer
    """);

This snapshot is likely to fail often even when the application is working correctly because the values are expected to change.

In such cases, targeted assertions provide clearer validation:

PlaywrightAssertions.assertThat(
    page.getByRole(
        AriaRole.HEADING,
        new Page.GetByRoleOptions().setName("Dashboard")
    )
).isVisible();

PlaywrightAssertions.assertThat(
    page.getByText("Notifications")
).isVisible();

Or use flexible matching:

PlaywrightAssertions.assertThat(page.locator("main"))
    .matchesAriaSnapshot("""
        - heading "Dashboard"
        - text: /Notifications \\d+/
    """);

Snapshot testing may also be a poor choice when:

- snapshots become very large
- failures are difficult to review
- baseline updates occur frequently
- the output changes more often than the feature itself
- business logic requires precise validation

For critical workflows, explicit assertions are usually better because they communicate intent clearly.

Example:

PlaywrightAssertions.assertThat(
    page.getByText("Payment successful")
).isVisible();

PlaywrightAssertions.assertThat(page)
    .hasURL(Pattern.compile(".*/orders/confirmation"));

These assertions clearly describe the expected business outcome and are easier to diagnose when they fail.

A practical rule is:

Use snapshot testing for:
- stable accessibility structure
- reusable UI components
- visual regression baselines
- broad regression coverage

Use assertions for:
- business rules
- exact values
- dynamic content
- user-visible outcomes
- workflow validation

Common mistake: using snapshots for highly dynamic pages and repeatedly updating baselines whenever they fail. If snapshot updates become routine maintenance rather than meaningful review, the test is no longer providing useful regression protection. Use focused assertions, partial matching, or regex-based matching instead.

Question 2.12

How can omitting accessible names or attributes make ARIA snapshot tests more flexible?

Interview-Style Answer

Omitting accessible names or attributes in an ARIA snapshot makes the test less strict. It allows the test to verify only the accessibility information that matters, such as role, hierarchy, or presence, without enforcing every label or state.

For example:

- button

checks that a button exists, but does not require a specific accessible name such as Submit, Save, or Continue.

Similarly:

- checkbox

checks that a checkbox exists, but does not require it to be checked or unchecked.

This is useful when names, values, or ARIA states are dynamic and not important to the test objective.

Detailed Explanation

ARIA snapshots can be written with very specific expectations.

Example:

- button "Submit" [disabled]

This means the accessibility tree must contain:

- role: button
- accessible name: Submit
- state: disabled

This is useful when the exact accessible name and state are part of the requirement.

But if the test only cares that a button exists, the accessible name can be omitted:

- button

Example:

<button>Submit</button>

Flexible ARIA snapshot:

PlaywrightAssertions.assertThat(page.locator("body"))
    .matchesAriaSnapshot("""
        - button
    """);

This focuses on the role. If the button text changes from Submit to Continue, the snapshot can still pass because the accessible name was not part of the expectation.

The same applies to attributes.

Specific snapshot:

- checkbox [checked]

Flexible snapshot:

- checkbox

By omitting [checked], the test checks only that a checkbox is present. It does not care whether the checkbox is currently checked, unchecked, enabled, or disabled.

This is useful when:

- accessible names contain dynamic values
- labels change based on user data or locale
- checkbox or toggle states are not relevant
- optional ARIA attributes vary by state
- the test only validates role and structure
- strict matching would create noisy failures

However, omission should be intentional. If the requirement is that a button must be named Pay now, then the name should be included:

- button "Pay now"

If the requirement is that a checkbox must be checked, then the state should be included:

- checkbox "Accept terms" [checked]

So, omitting names or attributes improves flexibility only when those details are not important to the scenario.

Common mistake: omitting important accessibility details just to make the test pass. If the accessible name, state, or attribute is part of the requirement, keep it in the snapshot; omit only dynamic or irrelevant details to avoid brittle tests.

3. Accessibility Testing

Part I - Core Questions

Question 3.8

How do you integrate axe accessibility checks with Playwright Java?

Interview-Style Answer

To integrate axe accessibility checks with Playwright Java, I would add the axe-core JavaScript file as a test resource, navigate the application to the required page state, inject axe into the page, run axe.run() using page.evaluate(), collect violations, and fail or warn based on the team’s agreed accessibility policy.

This is useful because axe can automatically detect many rule-based accessibility issues such as missing labels, invalid ARIA attributes, missing alt text, contrast problems, landmark issues, and form accessibility problems. However, axe should be treated as one layer of accessibility validation, not a complete replacement for keyboard testing, screen-reader testing, ARIA snapshot testing, and manual review.

Detailed Explanation

In a Playwright Java framework, axe is usually integrated by loading the axe-core script into the browser page and then executing axe.run() after the page reaches the state that needs to be tested.

A typical integration flow is:

1. Add axe-core JavaScript as a local test resource.
2. Navigate to the page or component state.
3. Wait until the important UI content is visible.
4. Inject axe into the page.
5. Run axe.run() using page.evaluate().
6. Collect accessibility violations.
7. Filter or classify violations based on severity, tags, or agreed rules.
8. Fail the test or attach violations to the report based on project policy.

Example idea:

import com.microsoft.playwright.*;
import com.microsoft.playwright.options.AriaRole;

import java.nio.file.Files;
import java.nio.file.Paths;

import static com.microsoft.playwright.assertions.PlaywrightAssertions.assertThat;

public class AccessibilityTest {
    public static void main(String[] args) throws Exception {
        try (Playwright playwright = Playwright.create()) {
            Browser browser = playwright.chromium().launch();
            Page page = browser.newPage();

            page.navigate("https://example.com/login");

            assertThat(page.getByRole(
                AriaRole.HEADING,
                new Page.GetByRoleOptions().setName("Login")
            )).isVisible();

            String axeScript = Files.readString(Paths.get("src/test/resources/axe.min.js"));
            page.addScriptTag(new Page.AddScriptTagOptions().setContent(axeScript));

            Object results = page.evaluate("async () => await axe.run(document)");

            System.out.println(results);

            browser.close();
        }
    }
}

In a real framework, the results object should be parsed properly and converted into a readable report. The framework can fail the test when violations match agreed conditions, such as serious or critical impact violations.

For example, the team may define a policy like:

- Fail the test for critical and serious violations.
- Warn for moderate violations during early adoption.
- Ignore only approved known issues with ticket references.
- Run checks on stable page states, not during loading.
- Attach violations to CI reports.

This policy is important because blindly failing on every issue without ownership can create noise, while ignoring all violations makes the check useless. The team should define scope, severity rules, allowed exclusions, reporting format, and ownership.

Axe checks are useful for detecting technical accessibility problems, but they do not prove the full user experience. For example, axe may detect a missing label, but it cannot fully judge whether the screen-reader flow is natural, whether alt text is meaningful, whether the instructions are clear, or whether the page is easy to use for users with cognitive disabilities.

Common mistake: assuming axe alone validates complete accessibility. Axe is valuable for automated rule-based checks, but it should be combined with role-based locators, ARIA snapshot testing, keyboard navigation checks, screen-reader review, and manual accessibility validation for critical flows.

Question 3.9

What are the limitations of automated accessibility testing?

Interview-Style Answer

Automated accessibility testing can catch many technical accessibility issues, but it cannot fully prove that a page is accessible for real users. Tools can detect problems such as missing labels, invalid ARIA attributes, broken roles, missing alt text, and some contrast issues, but they cannot fully judge screen-reader experience, content clarity, logical reading order, cognitive accessibility, or whether the UI is actually easy to use.

In Playwright Java, automated checks, ARIA assertions, keyboard checks, and accessibility scans are useful as regression safety nets. However, they should be combined with manual review, keyboard-only testing, screen-reader validation, and real user experience checks for critical flows.

Detailed Explanation

Automated accessibility testing is valuable because it can quickly detect many common accessibility problems during development and CI/CD execution. It helps prevent obvious issues from reaching production and gives teams fast feedback after UI changes.

Automated checks can help identify:

- Missing form labels
- Invalid ARIA attributes
- Incorrect or missing roles
- Missing alt text
- Some color contrast issues
- Some keyboard navigation problems
- Duplicate IDs
- Broken heading structure
- Missing accessible names
- Accessibility tree regressions

For example, a Playwright test can verify that an important button is exposed with a proper role and accessible name:

PlaywrightAssertions.assertThat(
    page.getByRole(
        AriaRole.BUTTON,
        new Page.GetByRoleOptions().setName("Submit")
    )
).isVisible();

ARIA snapshot testing can also help detect accessibility structure changes:

PlaywrightAssertions.assertThat(page.locator("body")).matchesAriaSnapshot("""
  - heading "Login" [level=1]
  - textbox "Email"
  - textbox "Password"
  - button "Sign in"
""");

But automated testing has limits because accessibility is not only about technical rules. A page can pass automated checks and still be difficult for users.

Manual review is still needed for:

- Whether screen-reader navigation feels natural
- Whether alt text is meaningful, not just present
- Whether instructions are clear
- Whether error messages are understandable
- Whether focus order matches the user journey
- Whether keyboard navigation is practical
- Whether headings create a logical content structure
- Whether the page is usable for users with cognitive disabilities
- Whether the design intent is accessible in real usage

For example, an image may have alt text, so an automated tool may not report a missing-alt violation. But if the alt text says only "image" or "banner", it is technically present but not meaningful. Similarly, a button may have an accessible name, but the complete screen-reader flow may still be confusing if the surrounding context is unclear.

Automated accessibility testing should therefore be treated as one layer of quality, not the complete solution. A strong accessibility strategy combines Playwright checks, ARIA snapshot testing, automated accessibility scans, keyboard testing, screen-reader testing, design review, and manual validation for important workflows.

Common mistake: claiming a page is accessible because automated scans show zero violations. Zero automated violations only means the tool did not detect rule-based issues; it does not prove that the page is fully usable, understandable, and accessible for real users.

4. Cross browser testing

Part I - Core Questions

Question 4.2

Should every Playwright Java test run on every browser?

Interview-Style Answer

No. Every Playwright Java test does not need to run on every browser. I would run critical workflows across all supported browsers and keep the full regression suite on the primary supported browser unless the product risk justifies wider coverage.

A good cross-browser strategy should be based on the product’s browser support matrix, customer usage, business criticality, past browser-specific defects, execution cost, and CI capacity.

Detailed Explanation

Running every test on Chromium, Firefox, and WebKit may increase execution time and CI cost without giving proportional value. Cross-browser testing is valuable, but it should be applied strategically.

A practical strategy could be:

Chromium:
- Full regression suite
- Main development feedback
- Broad functional coverage

Firefox:
- Smoke tests
- Critical workflows
- Browser-sensitive flows
- Areas with past Firefox defects

WebKit:
- Smoke tests
- Safari-sensitive workflows
- Responsive and mobile-like flows
- Critical forms, checkout, upload, download, and layout checks

Good candidates for cross-browser execution include:

1. Login and logout.
2. Registration or onboarding.
3. Checkout, payment, or order submission.
4. File upload and download.
5. Complex forms.
6. Date, time, select, number, and file inputs.
7. Responsive layouts.
8. Keyboard and focus-sensitive flows.
9. Dashboard or reporting pages.
10. High-value business workflows.

The framework should separate browser setup from test logic. For example, the same test should run with different browser values through Maven, Gradle, JUnit, TestNG, or CI matrix jobs.

Example:

mvn test -Dbrowser=chromium
mvn test -Dbrowser=firefox
mvn test -Dbrowser=webkit

Each browser run should use isolated BrowserContext instances, browser-specific reports, separate screenshots, traces, videos, downloads, and clear cleanup. This makes it easier to compare whether a failure is caused by browser behavior, test data, environment, or automation design.

The strategy should also distinguish project setup, browser-binary setup, and runtime behavior. Browser binaries must be installed and available in CI, but that does not mean every test must execute against every browser.

Common mistake: Using an extreme strategy: either running no cross-browser tests and missing real browser defects, or running the entire suite on every browser without considering business risk, execution time, CI cost, and browser support priorities.

Question 4.8

How can locator behavior differ across browsers in Playwright Java tests?

Interview-Style Answer

Locator behavior can appear different across browsers when the underlying page is exposed differently by Chromium, Firefox, or WebKit. Playwright’s locator API is consistent, but browser engines may differ in how they calculate visibility, accessible roles, accessible names, text rendering, focus behavior, shadow DOM behavior, or invalid HTML correction.

In Playwright Java, I would troubleshoot this by checking locator count, strict mode failures, visibility, accessible role and name, trace snapshots, screenshots, and whether the application markup is valid, semantic, and accessible across browsers.

Detailed Explanation

Role-based and accessibility-oriented locators are powerful, but they depend on the browser’s accessibility tree and the application’s HTML semantics. If the markup is weak, invalid, or inaccessible, different browsers may expose the same element slightly differently.

Examples of browser-sensitive locator issues include:

1. Icon-only buttons without accessible names.
2. Labels not properly associated with inputs.
3. Hidden text contributing differently to accessible names.
4. CSS-generated content affecting visible text expectations.
5. Elements hidden in one browser due to CSS support differences.
6. SVG buttons missing aria-label.
7. Placeholder text being used incorrectly as a label.
8. Invalid HTML being corrected differently by browser engines.
9. Text wrapping or font rendering changing visible text.
10. Duplicate accessible names causing strict mode failures.

Example:

Locator submitButton = page.getByRole(
    AriaRole.BUTTON,
    new Page.GetByRoleOptions().setName("Submit")
);

System.out.println("Submit button count: " + submitButton.count());

PlaywrightAssertions.assertThat(submitButton).isVisible();

submitButton.click();

If this passes in Chromium but fails in Firefox or WebKit, I would not immediately replace it with XPath or CSS. First, I would check whether the button has a proper semantic role and accessible name in all browsers. For example, an icon-only button should expose a meaningful name:

<button aria-label="Submit form">
  <svg></svg>
</button>

Then the test can use a stable role locator:

page.getByRole(
    AriaRole.BUTTON,
    new Page.GetByRoleOptions().setName("Submit form")
).click();

For repeated elements, the issue may not be cross-browser behavior but missing scoping. In that case, the locator should be scoped to a row, dialog, card, or section:

Locator row = page.getByRole(
    AriaRole.ROW,
    new Page.GetByRoleOptions().setName(Pattern.compile("ORD-101"))
);

row.getByRole(
    AriaRole.BUTTON,
    new Locator.GetByRoleOptions().setName("View")
).click();

A senior troubleshooting approach is to compare traces and screenshots across browsers, check whether the locator resolves to the same element, and decide whether the fix belongs in application accessibility, locator scoping, or test synchronization.

Common mistake: Blaming Playwright locator reliability when the real issue is invalid HTML, missing labels, duplicate accessible names, poor semantics, browser-specific visibility, or inaccessible UI that browsers expose differently.

5. Visual testing

Part I - Core Questions

Question 5.5

What makes visual tests flaky in Playwright Java?

Interview-Style Answer

Visual tests become flaky when screenshots capture unstable or environment-dependent UI states. Common causes include dynamic content, animations, timestamps, ads, random data, loading states, external images, different fonts, different viewport sizes, device scale factor differences, and CI rendering differences.

In Playwright Java, visual tests should compare a stable and repeatable UI state. The test should use controlled data, wait for the final visible state, keep browser and viewport settings consistent, and hide or control dynamic regions before screenshot comparison.

Detailed Explanation

Visual flakiness happens when the screenshot changes even though the application behavior is correct. Unlike normal locator assertions, screenshot comparison is sensitive to pixels, spacing, fonts, images, animations, and rendering differences.

Common visual flakiness causes:

1. Current date/time
2. Random IDs
3. Animations
4. Loading spinner
5. Dynamic charts
6. External images
7. Browser/font differences
8. Different viewport
9. Data changes
10. Cursor/focus state

For example, a test may fail in CI because a dashboard chart has different data, a timestamp changed, a web font loaded differently, or the screenshot was taken while a spinner was still disappearing. These are not always application bugs; they may be test stability issues.

A better approach is to wait for a meaningful final UI state before comparing screenshots:

PlaywrightAssertions.assertThat(
    page.getByTestId("dashboard-loaded")
).isVisible();

Locator dashboardCard = page.getByTestId("dashboard-card");

PlaywrightAssertions.assertThat(dashboardCard)
    .hasScreenshot("dashboard-card.png");

Dynamic regions should be controlled, hidden, or avoided when they are not part of the visual requirement:

page.locator("[data-testid='current-time']")
    .evaluate("el => el.style.visibility = 'hidden'");

PlaywrightAssertions.assertThat(
    page.getByTestId("report-summary")
).hasScreenshot("report-summary.png");

Stabilization methods:

- Use stable test data.
- Wait for the final UI state.
- Hide or mask dynamic sections.
- Disable or wait for animations where possible.
- Use consistent viewport and device scale factor.
- Keep browser versions and fonts consistent in CI.
- Prefer component screenshots over full-page screenshots.
- Capture trace, screenshot, and diff artifacts for failure analysis.

For reliable visual testing, the framework should separate real UI regressions from test noise. If a visual test fails, compare the expected, actual, and diff screenshots before updating the baseline. The cause may be a real layout issue, but it may also be unstable data, different rendering, missing fonts, or an early screenshot.

Common mistake: comparing screenshots before the page reaches a stable final state, which causes failures due to loading, animation, dynamic data, or environment differences instead of real visual regressions.

6. Playwright Vs Selenium

Part I - Core Questions

Question 6.4

How is Playwright Locator different from Selenium WebElement?

Interview-Style Answer

A Playwright Locator represents a way to find an element, while Selenium WebElement represents a specific element reference that has already been found in the DOM.

This difference is important for modern dynamic applications. In Selenium, a stored WebElement can become stale if the DOM is re-rendered. In Playwright Java, a Locator is re-evaluated when an action or assertion is performed, so it works better with dynamic UI updates, auto-waiting, and web-first assertions.

Detailed Explanation

In Selenium Java, when you call findElement(), Selenium returns a WebElement that points to a specific DOM node at that moment. If the page re-renders, replaces the element, or updates part of the DOM, that stored WebElement may no longer be valid and can cause a stale element problem.

In Playwright Java, a Locator is different. It does not permanently store one DOM node. It stores the strategy for finding the element. When you perform an action like click() or an assertion like isVisible(), Playwright resolves the locator at that time and applies its auto-waiting and actionability checks.

Example:

Locator saveButton = page.getByRole(
    AriaRole.BUTTON,
    new Page.GetByRoleOptions().setName("Save")
);

saveButton.click();

PlaywrightAssertions.assertThat(saveButton).isEnabled();

Here, saveButton is not a fixed DOM element reference like a Selenium WebElement. It is a reusable locator query. When click() runs, Playwright finds the matching button and waits until it is actionable. When the assertion runs, Playwright checks the current state of the matching button.

This improves reliability in SPAs where components are frequently re-rendered after API calls, state changes, validation updates, or route changes.

Good locator design still matters. The locator should represent user intent and target a unique, stable element. Prefer role locators, labels, accessible names, visible text, scoped locators, or stable test IDs where appropriate:

Locator submitButton = page.getByRole(
    AriaRole.BUTTON,
    new Page.GetByRoleOptions().setName("Submit order")
);

If a locator matches multiple elements, Playwright strict mode can fail actions that require a single element. In that case, improve the locator, scope it to a section, or use filter(), first(), last(), or nth() only when the choice is intentional.

Common mistake: treating Playwright Locator like a stored Selenium WebElement and adding unnecessary re-find logic, manual stale-element handling, or hard waits instead of relying on locator re-resolution, auto-waiting, and web-first assertions.

Question 6.8

How should Selenium XPath-heavy tests be migrated to Playwright Java?

Interview-Style Answer

Selenium XPath-heavy tests should not be migrated by simply copying the same XPath into Playwright Java. They should be reviewed and rewritten using Playwright’s user-facing locator strategy wherever possible, such as role locators, labels, text, placeholder, accessible names, scoped locators, and stable test IDs.

The goal is to make the test express user intent. For example, instead of locating the second button inside the third div, the test should locate the Approve button inside the row for invoice INV-1001. XPath can still be used when there is no better option, but it should not be the default migration strategy.

Detailed Explanation

A direct XPath-to-Playwright migration may technically work, but it carries old Selenium weaknesses into the new framework. Many Selenium suites contain fragile XPath selectors based on DOM position, nested div structure, indexes, CSS classes, or generated attributes. These selectors break easily when the UI is refactored, even if the user-visible behavior has not changed.

Weak migrated locator:

page.locator("//div[3]/button[2]").click();

This locator does not explain the user action. It depends on page structure and position, so it can break when another button, wrapper, or layout container is added.

A better Playwright Java locator is:

page.getByRole(
    AriaRole.BUTTON,
    new Page.GetByRoleOptions().setName("Approve")
).click();

This is more readable because it matches how the user understands the page: click the button named Approve.

For repeated elements such as tables, cards, and search results, the locator should be scoped by business identity:

Locator row = page.getByRole(AriaRole.ROW)
    .filter(new Locator.FilterOptions().setHasText("INV-1001"));

row.getByRole(
    AriaRole.BUTTON,
    new Locator.GetByRoleOptions().setName("Approve")
).click();

This is better than using row indexes because it says: find the invoice row for INV-1001, then click its Approve button.

Good migration rules include:

1. Replace positional XPath with role, label, text, placeholder, or test-id locators.
2. Use accessible names for buttons, links, inputs, and headings.
3. Scope locators to a section, row, card, dialog, or form before acting.
4. Use filter() when selecting from repeated UI elements.
5. Use nth(), first(), or last() only when the order itself is meaningful.
6. Keep XPath only for rare cases where user-facing locators are not available.
7. Improve the application markup if poor accessibility prevents stable locators.

XPath may still be acceptable for legacy pages, SVGs, complex DOM relationships, or areas without accessible markup. But even then, the XPath should be stable and intentional, not based on random hierarchy or indexes.

Common mistake: mechanically converting Selenium XPath selectors into page.locator("//...") without checking whether the locator represents user intent, uniqueness, accessibility, and long-term stability after UI refactoring.

7. Emulation (Mobile)

Part I - Core Questions

Question 7.8

What are the limitations of Playwright mobile emulation compared with real-device testing?

Interview-Style Answer

Playwright mobile emulation is useful for validating responsive layout, viewport behavior, touch support, device scale factor, user agent, locale, timezone, geolocation, and permissions. However, it does not fully replace real-device testing because it cannot completely reproduce physical hardware, mobile operating system behavior, real browser-device combinations, real network conditions, sensors, battery impact, performance, native keyboard behavior, or complex gesture-heavy workflows.

In Playwright Java, mobile emulation is configured through browser.newContext() options such as setViewportSize(), setScreenSize(), setDeviceScaleFactor(), setIsMobile(), setHasTouch(), setUserAgent(), permissions, locale, and timezone. Emulation should be treated as fast CI-friendly coverage, while real devices or cloud-device testing should be used for high-risk mobile scenarios.

Detailed Explanation

Playwright mobile emulation is excellent for catching many mobile and responsive defects early. It helps verify whether the mobile menu appears, desktop sidebar is hidden, cards stack correctly, buttons remain accessible, and layout behaves correctly across selected breakpoints.

Example mobile-like context in Playwright Java:

BrowserContext mobileContext = browser.newContext(
    new Browser.NewContextOptions()
        .setViewportSize(390, 844)
        .setScreenSize(390, 844)
        .setDeviceScaleFactor(3)
        .setIsMobile(true)
        .setHasTouch(true)
        .setUserAgent("Mozilla/5.0 Mobile")
);

Page page = mobileContext.newPage();
page.navigate(baseUrl + "/dashboard");

PlaywrightAssertions.assertThat(
    page.getByRole(
        AriaRole.BUTTON,
        new Page.GetByRoleOptions().setName("Menu")
    )
).isVisible();

Use Playwright emulation for:

1. CI-friendly responsive regression
2. Mobile navigation checks
3. Basic touch-enabled flows
4. Viewport and breakpoint testing
5. Locale, timezone, geolocation, and permission scenarios
6. Early detection of mobile layout defects

But real devices may still reveal issues that emulation cannot fully reproduce. These include actual device performance, mobile browser quirks, native keyboard behavior, physical touch gestures, camera behavior, biometric flows, sensor behavior, battery impact, device memory limitations, and real network variation.

Use real devices or cloud-device testing for:

1. High-risk mobile releases
2. Gesture-heavy features
3. Performance-sensitive mobile flows
4. Camera, biometric, sensor, or file-upload scenarios
5. Device/browser-specific production defects
6. Final confidence before major mobile releases

A good mobile test strategy does not depend only on one emulated device or one viewport. It uses a small responsive matrix in Playwright Java for fast automated feedback and adds real-device validation for the flows where actual hardware, browser, OS, performance, or touch behavior can affect the user experience.

Common mistake: Assuming Playwright mobile emulation gives 100% real-device confidence, instead of using it for fast responsive coverage and adding real-device or cloud-device testing for hardware, OS, performance, native keyboard, browser-specific, and gesture-heavy scenarios.

Question 7.15

When should you prefer browser.newContext() viewport configuration over page.setViewportSize()?

Interview-Style Answer

Prefer browser.newContext() viewport configuration when the test should start in a specific desktop, tablet, or mobile profile from the beginning of the page lifecycle. This is better for most responsive and mobile tests because the application loads directly with the intended viewport, mobile mode, touch support, user agent, locale, timezone, permissions, and storage state.

Use page.setViewportSize() when the test specifically needs to verify runtime resize behavior, such as how the UI reacts when the browser window changes size after the page is already loaded.

Detailed Explanation

Context-level viewport configuration is usually the cleaner and more realistic option for responsive testing. Many applications make layout or feature decisions during the initial page load. For example, the application may decide which navigation component to render, which API payload to request, which feature flags to enable, or whether to load mobile-specific JavaScript based on the initial viewport, user agent, or mobile context settings.

Example:

BrowserContext mobileContext = browser.newContext(
    new Browser.NewContextOptions()
        .setViewportSize(390, 844)
        .setIsMobile(true)
        .setHasTouch(true)
);

Page mobilePage = mobileContext.newPage();
mobilePage.navigate("https://example.com");

PlaywrightAssertions.assertThat(
    mobilePage.getByRole(
        AriaRole.BUTTON,
        new Page.GetByRoleOptions().setName("Menu")
    )
).isVisible();

This is better than loading the page as desktop and resizing later because the page starts directly in the intended mobile-like profile.

page.setViewportSize() is useful for a different purpose. It helps when the requirement is to test dynamic resizing after the page has already loaded.

Example:

Page page = context.newPage();
page.navigate("https://example.com");

page.setViewportSize(390, 844);

PlaywrightAssertions.assertThat(
    page.getByRole(
        AriaRole.BUTTON,
        new Page.GetByRoleOptions().setName("Menu")
    )
).isVisible();

This checks whether the application responds correctly to runtime viewport changes. That is useful for validating resize listeners, responsive CSS changes, collapsible layouts, or desktop-to-mobile transitions. But it may not be identical to a fresh mobile page load because some application behavior may be initialized only once during startup.

In a framework, I would normally create separate contexts for desktop, tablet, and mobile profiles using browser.newContext(). I would use page.setViewportSize() only for tests whose purpose is specifically to validate resize behavior.

Common mistake: Loading the page in desktop mode, resizing it to mobile with page.setViewportSize(), and assuming it is identical to opening the page directly in a mobile-configured BrowserContext. This can miss startup-time differences such as mobile navigation rendering, feature flags, API behavior, user-agent logic, and touch-specific behavior.

8. CI

Part I - Core Questions

Question 8.6

How would you make Playwright Java CI execution reliable across different build agents?

Interview-Style Answer

I would make Playwright Java CI execution reliable by standardizing the build environment across all agents. That includes Java version, Maven or Gradle version, Playwright Java version, browser binaries, OS image, required system packages, environment variables, timezone, locale, secrets, test data setup, and artifact collection.

For parallel CI execution, I would also ensure that each test uses isolated BrowserContext and Page, separate users where needed, parallel-safe test data, worker-specific files, and safe storage-state handling. The goal is that the same commit behaves the same way on every build agent.

Detailed Explanation

CI reliability depends heavily on reproducibility. If one build agent uses a different Java version, browser binary, OS package, timezone, locale, environment variable, or file path structure, the same Playwright Java test can pass on one agent and fail on another.

A reliable setup starts with a controlled CI image or agent configuration. The team should define approved versions for Java, Maven or Gradle, Playwright Java, and browser binaries instead of allowing each build agent to drift independently.

Recommended controls:

1. Use approved CI images or centrally managed build agents.
2. Pin Java, Maven, Gradle, and Playwright Java versions.
3. Install or cache Playwright browser binaries consistently.
4. Ensure required OS dependencies are available for browser launch.
5. Set explicit timezone and locale where tests depend on dates, currency, or formatting.
6. Use environment-specific configuration through variables, not hardcoded values.
7. Validate secrets and environment URLs before test execution.
8. Run a browser launch smoke check before starting the full suite.
9. Capture environment metadata in reports.
10. Store traces, screenshots, videos, logs, and reports with build number and commit ID.

For example, the CI report should make it easy to identify where the test ran:

Build: 1842
Commit: a7f9c21
Environment: QA
Browser: chromium
Java: 17
Playwright Java: 1.x
Agent: linux-agent-03
Timezone: Asia/Kolkata

Parallel execution also needs strict isolation. Browser isolation alone is not enough if tests share backend users, orders, carts, files, or storage-state files. Each test should use a fresh BrowserContext and Page, and each worker should use safe data and file locations.

Example:

BrowserContext context = browser.newContext(
    new Browser.NewContextOptions()
        .setStorageStatePath(Paths.get("auth/buyer-ci.json"))
);

Page page = context.newPage();

For worker-specific data:

String workerId = System.getenv().getOrDefault("CI_NODE_INDEX", "local");
String orderId = "ORD-" + workerId + "-" + UUID.randomUUID();

For worker-specific files:

Path downloadDir = Paths.get("target/downloads", workerId, UUID.randomUUID().toString());
Files.createDirectories(downloadDir);

This prevents one build agent or parallel worker from overwriting another worker’s downloads, uploads, traces, screenshots, temporary files, or test data.

The pipeline should also publish useful evidence when failures occur. If a test fails only on one agent, traces, screenshots, videos, console logs, network logs, and environment metadata help determine whether the issue is product behavior, test code, data collision, missing dependency, browser mismatch, or CI environment drift.

Common mistake: Debugging the test code repeatedly while ignoring CI environment drift, such as different browser binaries, Java versions, OS packages, timezone, locale, secrets, shared users, shared test data, or shared download folders across build agents.

Question 8.13

How would you configure headed and headless execution in Playwright Java?

Interview-Style Answer

I would configure headed or headless execution using BrowserType.LaunchOptions().setHeadless() and control it through a system property, environment variable, or framework configuration instead of changing source code.

In practice, headless mode is usually used in CI for speed and repeatability, while headed mode is useful for local debugging. Even when switching between headed and headless modes, each test should still use isolated BrowserContext, clean test data, separate users where needed, and worker-specific files for downloads, uploads, traces, and screenshots.

Detailed Explanation

Playwright Java supports headed and headless browser execution through launch options. The framework should make this configurable so the same test code can run locally in headed mode and in CI in headless mode.

Example:

boolean headless = Boolean.parseBoolean(
    System.getProperty("headless", "true")
);

Browser browser = playwright.chromium().launch(
    new BrowserType.LaunchOptions().setHeadless(headless)
);

Run in headless mode:

mvn test -Dheadless=true

Run in headed mode:

mvn test -Dheadless=false

A framework can also combine this with browser selection:

String browserName = System.getProperty("browser", "chromium");
boolean headless = Boolean.parseBoolean(
    System.getProperty("headless", "true")
);

BrowserType.LaunchOptions launchOptions =
    new BrowserType.LaunchOptions().setHeadless(headless);

Browser browser;

switch (browserName.toLowerCase()) {
    case "firefox":
        browser = playwright.firefox().launch(launchOptions);
        break;
    case "webkit":
        browser = playwright.webkit().launch(launchOptions);
        break;
    default:
        browser = playwright.chromium().launch(launchOptions);
}

Headed mode is useful when debugging locator issues, popups, visual behavior, animations, or responsive layout differences. Headless mode is better for CI because it is faster, easier to run on build agents, and does not require a visible desktop session.

However, changing headed/headless mode should not change the test design. The suite should still use:

- Fresh BrowserContext and Page per test
- Parallel-safe test data
- Separate users or role-specific storage state where needed
- Worker-specific downloads, uploads, screenshots, traces, and temp files
- Proper teardown after execution
- Useful artifacts for CI failures

If a test passes only in headed mode but fails in headless mode, the issue should be investigated using traces, screenshots, videos, browser/version comparison, viewport settings, timing, and environment differences. The solution should not be to permanently force headed mode in CI unless there is a very specific reason.

Common mistake: Hardcoding setHeadless(false) or editing source code every time debugging is needed, instead of controlling headed/headless mode through Maven, Gradle, CI variables, or framework configuration.

Question 8.16

How would you prevent timezone and locale drift between local and CI Playwright runs?

Interview-Style Answer

I would prevent timezone and locale drift by explicitly setting timezoneId and locale in Browser.NewContextOptions for tests where date, time, currency, number formatting, sorting, or localized text matters.

Local machines may run in Asia/Kolkata, while CI agents may run in UTC or another region. If the browser context is not controlled, the same test can display different dates, timestamps, currencies, or translated text in local and CI runs.

Detailed Explanation

Timezone and locale drift is a common CI issue in applications that display dates, calendars, reports, currency, invoices, timestamps, or region-specific formats. A test may pass locally because the developer machine uses one timezone and locale, but fail in CI because the build agent uses UTC, US locale, or a different system configuration.

In Playwright Java, the safer approach is to define timezone and locale explicitly when creating the BrowserContext:

BrowserContext context = browser.newContext(
    new Browser.NewContextOptions()
        .setTimezoneId("Asia/Kolkata")
        .setLocale("en-IN")
);

Page page = context.newPage();

This makes browser behavior more predictable. For example, if the application shows Indian date and currency formats, the test should not depend on whatever locale the CI runner happens to use.

Use explicit timezone and locale settings when validating:

- Calendar workflows
- Date pickers
- Report timestamps
- Time-based messages
- Booking or expiry dates
- Currency formatting
- Number formatting
- Locale-specific sorting
- Localized labels or messages

The expected values should also be calculated using the same intended timezone and locale. Otherwise, the browser may display 07/06/2026, while the Java-side expected value is calculated as 06/06/2026 because the machine timezone differs.

Example:

ZonedDateTime nowInIndia = ZonedDateTime.now(
    ZoneId.of("Asia/Kolkata")
);

DateTimeFormatter formatter = DateTimeFormatter
    .ofPattern("dd MMM yyyy")
    .withLocale(new Locale("en", "IN"));

String expectedDate = nowInIndia.format(formatter);

PlaywrightAssertions.assertThat(
    page.getByTestId("report-date")
).hasText(expectedDate);

For CI reliability, the framework can centralize these settings in context creation instead of repeating them in every test. Different test suites can also define different locale profiles if the product supports multiple regions.

Timezone and locale settings are browser-context controls. They improve consistency for web application behavior, but they do not replace testing on real devices or real regional environments when the product has device-specific, OS-specific, or native-app behavior.

Common mistake: Setting timezone or locale only on the CI machine or calculating expected dates using the local system timezone, while the Playwright browser context displays dates, times, currency, or localized text using a different timezone or locale.

9. AI

Part I - Core Questions

Question 9.3

What principles would you follow for using AI in a Playwright Java automation program?

Interview-Style Answer

I would use AI to improve speed, consistency, failure analysis, coverage insight, test review, and knowledge sharing, but I would keep evidence, human review, security, and framework standards as mandatory controls.

AI should assist Playwright Java automation engineers; it should not become the final authority for code, locators, assertions, mocks, failure classification, or release decisions. Every AI-generated test or recommendation should be reviewed, validated through execution, checked against framework standards, and supported by real evidence from traces, screenshots, logs, network data, CI results, or product behavior.

Detailed Explanation

AI can add value in a Playwright Java automation program by helping generate test ideas, review Page Objects, summarize failures, detect duplicate tests, identify flaky patterns, improve reports, and suggest locator or assertion improvements. But uncontrolled AI usage can create fake APIs, weak tests, unsafe data exposure, duplicated coverage, false confidence, and poor release decisions.

Important principles:

1. Use evidence-first recommendations.
2. Require human approval for code and framework changes.
3. Never share secrets, tokens, cookies, storage-state files, or sensitive artifacts carelessly.
4. Enforce Playwright Java framework standards.
5. Review all AI-generated tests before merge.
6. Validate AI output through compilation, execution, and CI.
7. Use AI for analysis and assistance, not blind authority.
8. Track AI recommendation accuracy over time.
9. Protect traces, screenshots, videos, logs, reports, and network payloads.
10. Use AI to reduce noise, improve confidence, and support better engineering decisions.

For example, if AI suggests fixing a locator failure, the recommendation should include evidence:

Evidence:
Trace shows two visible Approve buttons.

Risk:
A broad locator may click the wrong approval button.

Recommended fix:
Scope the locator to the row containing the target invoice ID.

Validation:
Run invoice approval tests and related table interaction tests.

A safer Playwright Java locator would be:

Locator row = page.getByRole(
    AriaRole.ROW,
    new Page.GetByRoleOptions().setName(Pattern.compile(invoiceId))
);

row.getByRole(
    AriaRole.BUTTON,
    new Locator.GetByRoleOptions().setName("Approve")
).click();

The same principle applies to AI-generated tests. A generated test should not be accepted just because it compiles. It must use stable locators, meaningful user-visible assertions, safe test data, isolated BrowserContext and Page usage, secure credentials, scoped mocks, clear cleanup, and CI-compatible execution.

I would also define governance: approved AI tools, prompt templates, prohibited data, artifact redaction rules, review checklists, CI validation, audit expectations, and escalation rules for risky recommendations.

Common mistake: using AI as a replacement for automation engineering judgment, instead of using it as a controlled assistant that improves Playwright test quality, debugging speed, review consistency, and release confidence.

Question 9.8

How would you train a Playwright Java team to use AI responsibly?

Interview-Style Answer

I would train the team to use AI as an assistant for drafting, reviewing, debugging, and learning, not as an authority that can replace engineering judgment.

The training should cover safe prompt writing, artifact redaction, Playwright Java framework standards, review of AI-generated code, CI validation, secret protection, and the limits of AI recommendations. Engineers should know how to detect hallucinated APIs, weak locators, missing assertions, unsafe data handling, duplicate scenarios, and misleading failure analysis before accepting AI output.

Detailed Explanation

Responsible AI usage requires both technical skill and judgment. A Playwright Java team should understand where AI is helpful and where it can be risky.

Training topics should include:

1. What AI can help with
2. What data must not be shared
3. How to redact traces, screenshots, logs, and network payloads
4. How to ask structured failure-analysis questions
5. How to review AI-generated Playwright Java code
6. How to validate locator and assertion quality
7. How to detect hallucinated APIs or TypeScript-style code in Java
8. How to use traces, screenshots, videos, logs, and network evidence
9. How to document AI-assisted decisions
10. When to escalate to senior engineers

For Playwright Java code generation, the team should be trained to check whether the output uses valid APIs, avoids Thread.sleep(), uses stable locators, respects BrowserContext and Page isolation, protects credentials, creates safe test data, and includes meaningful user-visible assertions.

For example, AI may generate a test that clicks a button and stops:

page.getByRole(
    AriaRole.BUTTON,
    new Page.GetByRoleOptions().setName("Submit")
).click();

The team should know this is incomplete unless the final business outcome is validated:

page.getByRole(
    AriaRole.BUTTON,
    new Page.GetByRoleOptions().setName("Submit")
).click();

PlaywrightAssertions.assertThat(
    page.getByText("Request submitted successfully")
).isVisible();

The team should also be trained on data safety. They should not paste credentials, tokens, cookies, storage-state files, customer data, payment details, confidential screenshots, or full production traces into AI tools unless the tool and process are approved for that data.

Responsible usage also means documenting AI-assisted decisions when needed. If AI recommends a locator fix, mock change, or failure classification, the engineer should verify it with trace evidence, run the impacted tests, and keep human ownership of the final decision.

Common mistake: giving teams AI tools without teaching safe prompt writing, artifact redaction, Playwright Java API validation, locator standards, assertion quality, secret protection, CI validation, and the limits of AI-generated recommendations.

Question 9.17

How would you prevent AI usage from weakening engineering skills in a Playwright team?

Interview-Style Answer

I would position AI as a learning, review, and productivity assistant rather than a replacement for engineering understanding. Engineers should be expected to understand, explain, and validate AI-generated recommendations before using them.

The team should continue developing skills in Playwright Java fundamentals such as locator design, actionability, web-first assertions, Trace Viewer analysis, BrowserContext management, test data strategy, network debugging, and framework design. AI should accelerate learning and problem-solving, not become a substitute for technical competence.

Detailed Explanation

One of the biggest risks of AI adoption is that engineers may begin accepting recommendations without understanding why they are correct. Over time, this can weaken debugging skills, framework design capability, code review quality, and technical ownership.

Good practices include:

1. Require engineers to explain AI-suggested fixes before merging them.
2. Review why a locator strategy is correct.
3. Review why a wait or assertion strategy is correct.
4. Use AI outputs as learning material during team discussions.
5. Keep manual debugging skills active.
6. Require engineers to analyze traces and failure evidence.
7. Keep framework design decisions human-led.
8. Pair junior engineers with experienced reviewers.
9. Encourage engineers to challenge AI recommendations.
10. Measure understanding, not just implementation speed.

For example, if AI suggests replacing:

Thread.sleep(5000);

with:

PlaywrightAssertions.assertThat(
    page.getByTestId("order-status")
).hasText("Submitted");

the engineer should be able to explain:

- Why hard waits are unreliable.
- Why web-first assertions are preferred.
- What condition is actually being validated.
- How the assertion improves reliability.
- How it behaves in CI and parallel execution.

Similarly, when AI recommends a locator change, engineers should understand why the new locator is more stable, whether it relies on accessible names, whether it is unique, and whether it will remain maintainable after UI changes.

Organizations should also continue conducting framework reviews, debugging workshops, failure-analysis sessions, and architecture discussions where engineers solve problems using traces, screenshots, videos, network logs, and Playwright behavior rather than relying solely on AI-generated answers.

A healthy AI-enabled team becomes stronger over time because AI handles repetitive analysis while engineers focus on deeper reasoning, framework design, risk assessment, and quality decisions.

Common mistake: allowing engineers to copy AI-generated Playwright Java code, locators, waits, assertions, or fixes into the framework without understanding why they work, how they affect reliability, or what trade-offs they introduce.

Question 9.34

How would AI help detect weak Page Object design?

Interview-Style Answer

AI can detect weak Page Object design by reviewing Playwright Java page classes for unclear responsibility boundaries, generic methods, duplicated locators, hidden assertions, mixed API setup, utility logic inside page classes, and missing component extraction.

A strong Page Object should represent user-facing actions and page-specific validations. Reusable widgets should become component objects, while API setup, data generation, file handling, and framework utilities should stay outside Page Objects. This keeps ownership clear, reduces duplication, improves review quality, and helps the suite scale in CI/CD.

Detailed Explanation

A weak Page Object often becomes a dumping ground for locators, business flows, assertions, API calls, test data setup, and utility logic. It may work initially, but over time it becomes hard to review, reuse, debug, and maintain.

AI can detect design issues such as:

1. Generic methods such as clickButton(), enterText(), or verifyText()
2. Missing business-readable methods such as submitOrder() or approveInvoice()
3. Test data creation inside Page Object classes
4. API calls mixed into UI page actions
5. Hidden assertions inside action methods
6. Same locator repeated across many classes
7. Very large page class representing multiple screens
8. Repeated table, card, modal, or menu logic not extracted into components
9. Framework utilities mixed with product page behavior
10. Page Objects owned by the wrong team or shared without clear rules

Better responsibility separation:

Page Object:
- User-facing page actions
- Page-specific validations
- Page-specific locators

Component Object:
- Reusable tables, modals, cards, menus, filters, and widgets

Utility or Service:
- API setup
- Test data generation
- File parsing
- Date handling
- Environment configuration
- Cleanup logic

Example of weak design:

class OrdersPage {
    void clickButton(String text) { }
    void createOrderThroughApi() { }
    void parseDownloadedFile() { }
    void assertOrderCreated() { }
}

Better design:

class OrdersPage {
    void submitOrder(String orderName) { }
    void shouldShowOrderStatus(String orderId, String status) { }
}

class OrderApiClient {
    String createDraftOrder(OrderRequest request) { return "ORD-1001"; }
}

class DownloadFileVerifier {
    void shouldContainOrderId(Path file, String orderId) { }
}

AI can also help during PR review by flagging Page Objects that are growing too large, duplicating component logic, hiding assertions inside action methods, or mixing setup and UI behavior. These findings help teams maintain readable code, clear ownership, reusable components, and scalable automation architecture.

Common mistake: calling any class with locators a Page Object even when it mixes UI actions, assertions, API setup, test data, file utilities, and multiple screen responsibilities without clear design boundaries.

Question 9.45

How would you design confidence scoring for AI Playwright failure recommendations?

Interview-Style Answer

I would design confidence scoring based on evidence strength, artifact completeness, historical pattern match, reproduction consistency, and whether multiple signals point to the same root cause.

For Playwright Java failure analysis, a high-confidence recommendation should be backed by trace evidence, screenshot or video state, console or network logs, CI history, retry behavior, and a known failure pattern. If the evidence is incomplete or multiple causes are possible, the AI should clearly mark the recommendation as medium or low confidence.

Detailed Explanation

Confidence scoring should not be a random percentage. It should explain why the AI believes a recommendation is strong, uncertain, or weak.

Useful confidence factors include:

1. Trace Viewer confirms the failing page state
2. Screenshot or video supports the same conclusion
3. Network response or console error matches the suspected cause
4. Same failure pattern occurred previously
5. Failure is reproducible in retry or rerun
6. Test data setup confirms or rejects data-related issues
7. Browser and environment behavior are consistent
8. Recent code changes are linked to the failing module
9. Known issue or known fix exists
10. No conflicting evidence is found

A simple confidence model can be:

High confidence:
- Same error pattern occurred before
- Trace confirms the same page state
- Network or console evidence matches
- Failure is reproducible
- Known fix or known owner exists

Medium confidence:
- Error pattern is similar to previous failures
- Some artifacts support the suspected cause
- Artifacts are incomplete
- Root cause is likely but not fully proven

Low confidence:
- Only stack trace or timeout message is available
- No trace, screenshot, video, or network evidence
- Multiple root causes are possible
- Failure is new, inconsistent, or not reproducible

Example:

Recommendation:
Likely backend issue in invoice loading.

Confidence:
High

Evidence:
- Trace shows invoice table stayed in loading state.
- Network log shows /api/invoices returned 504.
- Screenshot confirms the loading spinner remained visible.
- Same pattern occurred five times in staging this week.
- Retry passed after the API returned 200.

Another example:

Recommendation:
Possible locator issue.

Confidence:
Low

Evidence:
- Only timeout error is available.
- No trace or screenshot was captured.
- The locator may be wrong, but page state is unknown.
- Test data and network behavior were not available.

This makes AI recommendations safer because engineers can see the level of uncertainty before acting. High-confidence recommendations may be triaged faster, while medium and low-confidence cases should require deeper engineer review before changing test code, quarantining tests, or raising defects.

Common mistake: showing AI failure recommendations without confidence level, supporting evidence, uncertainty, or explanation of why the recommendation should be trusted.