QA Engineer interview questions

Implicit and explicit waits serve different scopes, so I avoid combining them.

• An implicit wait globally polls every element lookup, while an explicit wait polls one condition at a specific point.
• Mixing them makes total wait times unpredictable because the driver and explicit condition poll within each other.
• I set the implicit wait to zero and use explicit conditions that document what the test needs.

Playwright auto-waits for actionability, but application readiness may require a separate signal.

• Before a click, it waits for the element to be attached, visible, stable, enabled, and unobscured.
• This is insufficient when data is loading, a debounced action has not fired, or the assertion depends on a background request.
• I wait for the real signal with an assertion, a specific response, or a UI state that appears only when data is ready.

I prioritize stable, meaningful locators and use long XPath chains only for unchangeable legacy DOM.

• My first choice is an agreed test attribute such as data-testid because it survives styling and copy changes.
• Next come role and accessible name, then stable IDs or short CSS selectors.
• Long positional XPath chains encode layout rather than meaning and break during ordinary DOM refactoring.

A Page Object should model the page and user actions without owning test expectations or scenarios.

• It contains page locators, meaningful actions, and navigation that can return the next Page Object.
• Assertions, test-data decisions, and test-flow logic stay in the test so its intent remains visible.
• I keep objects thin and split large pages into component objects such as headers, tables, and modals.

I create complex preconditions through the fastest reliable non-UI path and reserve the UI for the behavior under test.

• API calls or a data factory through the service layer can create the subscribed user and past orders during setup.
• Building that state through registration and checkout makes tests slow and lets one upstream bug break many unrelated cases.
• I use direct database inserts only when no API exists because they bypass business rules and may create impossible states.

I choose among Selenium, Cypress, and Playwright based on architecture, ecosystem, and project constraints.

• Selenium uses WebDriver and offers the broadest language, browser, and grid support, but synchronization is largely manual.
• Cypress runs alongside the app in the browser with strong debugging and waiting, but historically had multi-tab, multi-origin, and browser limits.
• Playwright offers auto-waiting, network interception, traces, and parallelism, while Selenium may fit an existing Java or grid ecosystem better.

I wait for positive evidence that the application is ready rather than merely waiting for a loader to disappear.

• Reliable signals include visible data, the specific response feeding the view, or an exposed state such as data-loaded.
• Spinner disappearance is fragile because chained requests can create a false ready moment between loaders.
• Fixed sleeps are worse because they fail in slow environments and waste time in fast ones.

StaleElementReferenceException means a stored element points to a DOM node that has been replaced or detached.

• State changes in frameworks such as React often replace subtrees and invalidate cached element references.
• The proper fix is to locate the element at interaction time and re-find it if staleness occurs, rather than cache it across actions.
• Playwright locators already re-resolve for each action, and Selenium wrappers can follow the same pattern.

Independent tests give clear failures, support parallel execution, and remain runnable in isolation.

• Dependencies cause cascade failures and turn one regression into many misleading red tests.
• Each test creates uniquely identified data through its own setup and never relies on a previous test or shared account state.
• Randomizing execution order in CI exposes hidden coupling before it becomes established practice.

I reuse authenticated state by role so login does not dominate an E2E suite.

• I authenticate through the API or one UI login, save cookies or storage state, and inject it into each test context.
• A small dedicated set still tests the UI login flow itself instead of repeating it in every scenario.
• I handle token expiry and give parallel workers separate users to prevent shared-account interference.

Iframes and shadow DOM require the automation to cross different element boundaries explicitly.

• Selenium switches into and out of an iframe, while Playwright addresses it with frameLocator.
• Open shadow roots can be queried with modern Playwright and Selenium CSS support, but closed roots need a developer-provided test hook.
• I wrap frame and shadow-root handling in Page Objects so scenario code remains focused and readable.

I automate file flows through browser APIs and verify the actual artifact, not just the visible interaction.

• For upload, I set a small repository fixture on the input with setInputFiles or sendKeys and intercept a chooser only for custom widgets.
• For download, I save without prompts, wait for the download event, and check the file name and size.
• I parse formats such as CSV or PDF to verify content because a file appearing does not prove it is correct.

Every CI UI failure should automatically preserve enough evidence for remote diagnosis.

• I capture a failure screenshot, run video, browser console, network logs, and a Playwright trace when available.
• Trace or video shows the UI state, console logs expose client exceptions, and network logs separate UI failures from backend errors.
• Automatic artifacts are a framework requirement because CI-only failures are otherwise expensive to reproduce locally.

For each risk, I choose the cheapest test layer that can detect it reliably.

• Unit and integration tests cover business logic and edge cases, while contract and API tests cover validation, permissions, and service errors.
• E2E keeps only a few journeys proving that integrated parts complete critical outcomes such as checkout and payment.
• This avoids an inverted pyramid of slow UI tests repeating checks that lower layers can perform in milliseconds.

I automate scenarios whose repetition and regression risk justify their implementation and maintenance cost.

• Core happy paths, API-level boundaries and permissions, and checks repeated every release usually earn automation.
• One-off exploration, rapidly changing UI, and subjective visual quality are often cheaper and better to test manually.
• I explain that automation is maintained code, while exploratory testing remains an intentional part of the plan.

I choose hard or soft assertions according to whether later checks remain meaningful after a failure.

• A hard assertion stops immediately, which is correct when later actions depend on the failed prerequisite.
• Soft assertions collect independent differences, such as multiple form fields or report columns, and report them together.
• Where a framework requires assert-all, I enforce it through fixtures so a forgotten final call cannot produce a false pass.

One profile-based configuration mechanism lets the same suite run unchanged across environments.

• A single switch selects base URLs, credential references, feature flags, and timeouts from environment variables or profile files.
• CI injects secrets from a secret store, while local runs use an ignored environment file.
• Tests use logical names such as admin user or payments sandbox, and never hardcode environment-specific values.

Visual regression testing compares captured UI images with approved baselines and requires deliberate scoping.

• Tools use pixel or perceptual diffs, thresholds, and ignored regions for dynamic content before human review.
• It pays off for stable design systems, component libraries, and important pages where unintended CSS changes matter.
• I stabilize data and animations, avoid volatile full pages, and review baseline updates as part of the PR flow.

My mobile coverage matrix follows the shipped product and real usage risks rather than trying every device.

• Responsive web gets broad browser emulation for layout and viewport logic plus a small real-device check for touch and rendering quirks.
• Native or hybrid apps use emulators for most runs and a device farm of leading real devices for release verification.
• Real devices target gaps such as old-hardware performance, permission dialogs, and interruptions like calls.

I run broad functional coverage on one primary browser and target cross-browser checks where engines actually differ.

• The full suite usually runs on Chromium because most functional defects are browser-independent.
• Critical journeys and browser-sensitive rendering, input, or API cases also run on Firefox and WebKit.
• Product analytics determines the matrix, while low-usage browsers receive documented smoke coverage or none.