Microsoft QA Engineer (Junior Level) Interview Preparation Guide

Direct answer

For a legacy module with poor coverage and frequent bugs, a 4-week risk-based plan should spend the first few days scoring the module's sub-areas by defect history and business impact, then concentrate the sprint's limited testing effort on the highest-risk sub-areas first, banking a few cheap, high-value quick wins early to build momentum and demonstrate progress.

Structured elaboration

Week-by-week structure:

• Days 1-2: inventory the module's functional sub-areas and score each by recent defect frequency (which parts of this module have generated the most bug reports) and business impact (which parts, if broken, cause the most damage). This produces a ranked list, not a flat "test everything a little."
• Week 1 remainder: quick wins first, meaning cheap, high-confidence tests on the highest-scoring sub-areas: adding basic regression coverage for the specific bugs that have already been reported and fixed here before (a bug that recurred once is likely to recur again without a regression test locking in the fix).
• Weeks 2-3: deeper coverage on the top-ranked sub-areas, including edge cases and negative paths, not just the happy path; this is where most of the sprint's effort concentrates.
• Week 4: a final pass focused on integration points between this module and the rest of the system, since legacy modules with poor coverage frequently have their worst bugs at integration boundaries rather than within a single function, plus a wrap-up documenting what was covered and what risk remains for the sub-areas that did not make the cut in 4 weeks.

Prioritization criteria: defect history (has this broken before), business impact (what does it cost when it breaks), and code complexity or recent change frequency (is this an area likely to have undiscovered bugs even without a history of reported ones).

Worked example

Suppose the legacy module has four sub-areas: order calculation (frequent past bugs, high business impact), user notification formatting (occasional cosmetic bugs, low impact), data export (rare bugs, moderate impact), and an internal admin override function (no reported bugs, but very high impact if it silently misbehaves since it bypasses normal validation). Scoring these by defect history times impact would initially rank order calculation highest and might rank the admin override function low due to no reported history, but risk-based prioritization corrects for this by weighting impact heavily even without a defect history: an override function with zero reported bugs but a "silently corrupts data if misused" failure mode deserves early attention precisely because its lack of history could mean nobody has looked closely, not that it is safe.

Quick wins in week 1: add regression tests locking in the fixes for the three most recent order-calculation bugs (cheap, since the correct behavior is already known from the bug reports), immediately reducing the chance of the same class of bug recurring. Weeks 2-3 go deep on order calculation edge cases (currency rounding, discount stacking, partial-order scenarios) and start on the admin override function's validation logic. Week 4 covers the integration between order calculation and the notification system, and documents that data-export coverage remains thin, an accepted, explicitly communicated gap given the 4-week constraint.

Trade-offs and pitfalls

The main pitfall is letting defect history alone drive the ranking and missing high-impact areas that simply have not been tested or used enough yet to have generated bug reports, which is exactly the admin override function's risk profile here. The other pitfall is spending all 4 weeks on deep coverage of one area and leaving zero time for integration testing, since integration boundaries in legacy code are disproportionately likely to hide the most damaging class of bug.

Direct answer

A comprehensive API testing approach layers several distinct concerns on top of each other: functional correctness first, then schema validation, then error handling, then auth, and finally the contract between this service and whoever consumes it, each one catching a different class of bug the others wouldn't.

Structured elaboration

Functional checks. Does each endpoint do what it's supposed to for valid input: correct status codes, correct data in the response, correct side effects (a POST actually creates what it claims to). This is the foundation everything else builds on.

Schema validation. Beyond "does the happy path work," does the response's SHAPE match what's documented or agreed, every time, not just in the cases someone happened to manually check. This catches drift between implementation and documentation that functional testing alone, if it only asserts on a few specific fields, can miss.

Error handling. Deliberately sending invalid, malformed, or edge-case input and confirming the API fails predictably and informatively, the right status code, a clear error message, rather than a generic 500 or, worse, silently accepting bad input and producing corrupted state.

Authentication and token flows. Confirming protected endpoints actually enforce auth (reject missing/invalid/expired credentials) and that the specific token lifecycle, issuance, refresh, expiry, revocation, behaves correctly, not just that a valid token happens to work once.

Rate-limiting behavior. Confirming the API actually throttles once a client exceeds its limit, and that it communicates that throttling clearly (a 429 with retry guidance) rather than degrading in some undocumented way.

Contract testing. Where this service has consumers (other services, or the same service's client SDK), consumer-driven contract tests confirm the service continues to honor what those consumers actually depend on, catching a class of regression, "this change is fine in isolation but breaks a real caller", that testing the service by itself can't see.

Tools. For manual and exploratory work, a tool like Postman is fast to work in interactively. For the durable, CI-enforced regression suite, a code-based framework (REST-Assured for a Java stack, pytest with requests for Python) integrates naturally with the rest of the codebase's testing and CI setup. For contract testing specifically, a dedicated tool like Pact handles the consumer/provider verification workflow that a general-purpose HTTP testing library doesn't natively support.

Exploratory vs. automated. Exploratory testing, poking at an API by hand, trying inputs nobody thought to write a formal test for, is how you DISCOVER what needs testing, especially early on or when integrating with something unfamiliar. The automated suite is where you PRESERVE that discovery so it keeps being checked on every future change; a bug found exploratorily that never gets turned into an automated test only protects you once.

Trade-offs and pitfalls

Treating this as one flat checklist to complete once, rather than as several genuinely different KINDS of testing each with their own cadence and depth, undersells how differently these axes need to be maintained: schema validation and functional tests belong on every CI run, contract tests need active coordination with real consumers to stay meaningful, and exploratory testing is an ongoing practice, not a phase you finish. Comprehensive doesn't mean "one big suite that does everything the same way," it means each of these concerns getting the specific kind of attention it actually needs.

Direct answer

I'd take anonymous feedback about my review style seriously precisely because it's anonymous, since that channel usually exists for exactly the kind of correction a junior colleague can't safely raise face to face. I'd gather independent evidence before assuming it's fully accurate, change specific, concrete behaviors rather than vaguely resolving to "be nicer," and check afterward whether it actually landed.

Structured elaboration

Reflect without dismissing it because of the channel. "If it mattered they'd say it to my face" throws away real signal; anonymity is often the only way someone junior can safely name a pattern involving a more senior reviewer. Treat the anonymity as informative about the power gap, not as a reason to discount the claim.

Gather more evidence before concluding anything. Reread recent review comments cold, as if someone else wrote them. Ask a trusted peer to look at the same threads without telling them what to look for, so you're not just confirming your own priors. If a real, low-pressure relationship allows it, ask a junior colleague directly, without putting any one person on the spot for the anonymous report.

Change concrete behaviors, not a vague intention. Separate "this is wrong" from "this is unacceptable" in tone. Lead with a question about reasoning before a directive. Distinguish blocking issues from nits explicitly, in writing, so severity isn't left to guesswork. Calibrate for the fact that terse, written comments read blunter than the same words said out loud.

Measure whether it worked. Track your own review tone informally over the following weeks. Ask a couple of the more junior people you review most, directly, whether reviews feel different. Watch a leading indicator like whether people started avoiding requesting your review, and whether that reverses.

Worked example

I got anonymous feedback through an engineering-culture survey that my code reviews came across as harsh and demotivating to junior engineers. Instead of dismissing it as one disgruntled respondent, I pulled up my last fifteen or so review threads and reread them cold. The pattern was real: comments like "this is wrong, fix it" with no explanation, several blocking-tone comments on things that were actually just style preferences. I asked a peer I trusted to look at the same threads without telling them what I was checking for, and they independently flagged the same terse, directive pattern.

I changed specific habits: opened comments with a question about reasoning ("what's the thinking behind choosing X here?") before any directive, tagged nits explicitly as "nit:" so they read as optional rather than blocking, and on any review with more than a couple of issues, started with something specific I liked before listing problems. Three months later I checked in directly with two of the junior engineers I reviewed most and asked plainly whether reviews felt different; both said yes, genuinely, not just politely. I also noticed their average turnaround time on my review comments dropped from roughly three days to under one, a proxy that they weren't dreading opening the feedback anymore.

Trade-offs and pitfalls

Dismissing the feedback because it's anonymous discards the exact signal the channel was built to surface. Overcorrecting into vague, uncritical praise stops the review from catching real problems, which is its own failure. Assuming a single round of changes fixed it, without checking back, means you don't actually know whether it worked. And most people who come across as harsh don't experience their own comments as harsh, so trusting your own read of your tone over the actual evidence is the mistake that got you here in the first place.

Overview / Goal
Maintain a reliable, fast regression suite that evolves with the product, minimizes false positives, and keeps technical debt manageable.

Process

• Triage cadence (weekly): review new failures, tag flaky vs genuine, assign tickets.
• Ownership: each feature team owns regression tests for their area; QA owners maintain cross-cutting smoke/regression suites. Define owner in test metadata.

Handling obsolete tests

• Mark tests impacted by removed features as "candidate‑obsolete".
• Add PRs that deprecate tests with links to product change; run a 2‑release hold before deletion.
• Archive test code and history for audit.

Refactoring test code

• Regular refactor sprint: extract page objects, shared fixtures, utilities.
• Enforce linting, test patterns, and CI gate checks for new tests.
• Peer review required for test changes.

Keeping test data current

• Use stable fixtures and factory data; prefer API/DB setup over UI seeding.
• Version test data; refresh monthly; secure environment for destructive cases.

Reviewing flaky tests

• Tag flaky tests; quarantine runs in CI to avoid failing pipeline.
• Create bug tickets with reproducible steps and telemetry; prioritize fixing flakiness by root cause (timing, async, environment).
• If unresolved after SLA, remove from critical suite and monitor.

Governance & Metrics

• Review cadence: monthly regression audit, quarterly cleanup.
• Metrics: flakiness rate, test pass rate, run time, coverage delta.
• Accept/remove policy documented (who approves, required evidence).

Outcome: predictable regression feedback, faster CI, reduced noise, clearer ownership.

I would frame the discussion around user impact, risk, and reversibility. A workaround is a temporary fix that reduces pain now, while the root issue is the underlying cause we still need to solve. I would ask: how many users are affected, how severe is the problem, and how risky is the workaround itself?

If the workaround is low risk and reversible, I would lean toward shipping it now and scheduling the root fix immediately after. For example, if users are blocked by a broken validation rule and we can safely relax it, I would ship the workaround, monitor errors, and commit to the deeper fix in the next cycle. If the workaround could corrupt data or create a bigger support burden, I would slow down and fix the root issue first.

I would make the decision explicit, document the trade-off, and assign an owner for the follow-up fix. That way the team is not pretending the workaround is the final answer, and users get relief as soon as it is safe to do so.

Situation & Goals
I would lead a fast, structured investigation to: 1) keep the customer informed, 2) gather safe diagnostics under privacy rules, 3) reproduce the issue in a customer-like environment, and 4) deliver temporary mitigations and a timeline for full remediation.

Immediate escalation & communication (0–4 hours)

• Acknowledge receipt within 30 minutes; assign severity, incident owner, and escalation path.
• Provide an ETA for first update (2 hours) and daily cadence until resolved.
• Ask for business impact, exact timestamps, user IDs (if permissible), and consent for diagnostics.

Data collection respecting privacy (0–8 hours)

• Request sanitized logs, screenshots, request/response traces; provide secure upload link.
• If PII required, request customer's secure session or signed DPA addendum and use encryption.
• Share minimal repro steps and any correlation IDs.

Reproduce in customer-like environment (4–24 hours)

• Create an environment matching customer config: OS, version, feature flags, traffic patterns, data volume.
• Use customer-provided traces and a replay tool to simulate requests.
• If timing-related, run stress and concurrency tests and record deterministic traces.

Remote debugging & instrumentation (8–48 hours)

• Propose non-invasive remote debugging: elevated log levels, sampling, feature-flagged diagnostic builds.
• Offer a joint session (screen-share) or remote session with their ops to attach debuggers, using strict access controls.
• Deploy temporary telemetry (trace IDs, extra metrics) with auto-expiry.

Temporary mitigations (within 24 hours)

• Recommend immediate workarounds: disable feature flag, rate-limit affected endpoints, roll back recent deploy if safe.
• Validate mitigations in staging-like replica and coordinate timed rollout.

Resolution plan & timelines

• Short-term fix/mitigation: within 24–48 hours.
• Root-cause analysis & permanent fix: 3–10 business days depending on complexity.
• Final postmortem and preventive test cases: within 7–14 days.

Follow-up & prevention

• Add regression and synthetic tests, update monitoring alerts, and document reproducible steps.
• Close with a post-incident review with customer and internal stakeholders.

I would focus on timely, transparent communication, strict privacy controls, reproducible experimentation, and clear timelines so the customer stays informed and protected while we resolve the defect.

Direct answer

Write the test to CONSUME an existing LoginPage object: the page object owns the locators and the one login(username, password) action, and the test itself only calls that action and asserts on the outcome, with setup/teardown and parametrized credential sets handled at the test level, not inside the page object.

Structured elaboration

A Page Object is a thin wrapper around ONE page's elements and the actions a user can take on it. The dividing line that matters here: the page object exposes a business-meaningful method (login), never raw selectors leaking into the test, and it does not assert anything itself, since assertions belong to the test, not the page. Parameterizing the credential sets is a separate, orthogonal concern from the page object's design: @pytest.mark.parametrize supplies each credential pair to the same test body, and the page object does not need to know or care how many times it gets called.

For setup/teardown, a real test would create a fresh WebDriver session per test (function-scoped fixture, driver.quit() in teardown) so credential sets do not share browser/session state across parametrized runs, which matters because a leftover cookie or "remember me" state from one credential pair could otherwise mask a login bug on the next.

Worked example

import pytest
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

class LoginPage:
    USERNAME = (By.ID, "username")
    PASSWORD = (By.ID, "password")
    SUBMIT = (By.ID, "login-btn")

    def __init__(self, driver):
        self.driver = driver
        self.wait = WebDriverWait(driver, 10)

    def login(self, username, password):
        self.wait.until(EC.presence_of_element_located(self.USERNAME)).send_keys(username)
        self.driver.find_element(*self.PASSWORD).send_keys(password)
        self.driver.find_element(*self.SUBMIT).click()

@pytest.fixture
def driver():
    from selenium import webdriver
    d = webdriver.Chrome()          # a real suite: one fresh session per test
    yield d
    d.quit()

@pytest.mark.parametrize("username,password", [
    ("user1", "pass1"),
    ("user2", "pass2"),
    ("invalid", "wrongpass"),
])
def test_login_flow(driver, username, password):
    driver.get("https://example.com/login")
    page = LoginPage(driver)
    page.login(username, password)

No browser binary is available in this environment, so the page object's CONTROL FLOW (not real browser rendering) was verified separately against a mocked driver, asserting the exact sequence of locator calls LoginPage.login makes for each parametrized credential pair:

from unittest.mock import MagicMock

@pytest.fixture
def driver():
    d = MagicMock()
    d.find_element.return_value = MagicMock()
    return d

@pytest.mark.parametrize("username,password", [
    ("user1", "pass1"),
    ("user2", "pass2"),
    ("invalid", "wrongpass"),
])
def test_login_flow_mocked(driver, username, password):
    page = LoginPage(driver)
    page.login(username, password)
    assert driver.find_element.call_args_list == [
        ((By.ID, "username"),),
        ((By.ID, "password"),),
        ((By.ID, "login-btn"),),
    ]

$ pytest test_login_pom_mock.py -v
test_login_flow_mocked[user1-pass1] PASSED
test_login_flow_mocked[user2-pass2] PASSED
test_login_flow_mocked[invalid-wrongpass] PASSED
3 passed in 0.16s

This confirms, against the real installed Selenium 4 API (By, WebDriverWait, expected_conditions, not hand-typed from memory), that the page object calls find_element(By.ID, "username") (via the WebDriverWait-guarded lookup), find_element(By.ID, "password"), and find_element(By.ID, "login-btn") for every credential pair, in that order, regardless of which pair is under test. (The webdriver.Chrome()-based driver fixture above is what a real suite would run against a live browser; this mocked version is only for verifying the page object's logic here.)

Trade-offs and pitfalls

The most common mistake is putting the assertion inside the page object (e.g. a login_succeeded() method that itself asserts), which makes the page object opinionated about what "success" means for every caller; a page object should expose state (is the dashboard visible?) and let the TEST decide what that state should be for a given credential pair. A second pitfall is sharing one browser session across all three parametrized credential sets to save setup time: that shortcut trades correctness for speed, since a stale session can hide or fake a login result. Finally, WebDriverWait with a hardcoded 10-second timeout is a reasonable default but should be a configurable constant, not repeated as a magic number across every page object in a real suite.

Direct answer
Case-insensitive email dedup looks like a one-line LOWER() fix, but the test data has to cover six distinct failure modes: exact duplicates, NULL, empty strings, casing differences, surrounding whitespace, and Unicode-normalized forms that look identical but are different byte sequences. The last one is the trap: LOWER(TRIM(email)) handles the first five correctly but does NOT dedupe Unicode-normalization variants, and that has to be surfaced as a real limitation, not silently assumed away.

Structured elaboration
Each row category exercises a different part of the normalization logic:

• Duplicates and casing: Alice@Example.com, alice@example.com should collapse to one identity; this is the core equivalence class the feature exists for.
• Leading/trailing whitespace: " alice@example.com " is semantically the same address but a byte-different string; a dedup that only lowercases without trimming will keep it as a false-distinct row.
• NULL and empty string: these are two DIFFERENT edge cases, not one. NULL fails equality comparisons in SQL (NULL = NULL is NULL, not TRUE), so a naive GROUP BY email silently puts every NULL row in its own untouched bucket (or drops them, engine-dependent) rather than merging them, while an empty string '' is a valid (if useless) value that DOES group correctly with other empty strings. The dedup logic must decide, explicitly, whether NULL and '' count as "no email" (excluded from dedup entirely) or as data to be deduplicated like any other value.
• Unicode-normalized forms: café@example.com can be encoded as one composed codepoint for é (Normalization Form Canonical Composition, NFC) or as e followed by a separate combining acute accent character (Normalization Form Canonical Decomposition, NFD). Both render identically on screen and are the same logical string, but they are different byte sequences, so LOWER()/TRIM() treat them as distinct.

Worked example
Test dataset (SQLite, run for real):

CREATE TABLE users (id INTEGER PRIMARY KEY, email TEXT);
INSERT INTO users (id, email) VALUES
  (1, 'Alice@Example.com'),
  (2, 'alice@example.com'),
  (3, '  alice@example.com  '),
  (4, 'BOB@EXAMPLE.COM'),
  (5, NULL),
  (6, ''),
  (7, 'carol@example.com'),
  (8, 'café@example.com'),                       -- NFC: e-with-acute is one codepoint
  (9, 'cafe' || X'0301' || '@example.com');       -- NFD: plain e + combining acute accent (U+0301)

SELECT LOWER(TRIM(email)) AS normalized_email, COUNT(*) AS row_count, GROUP_CONCAT(id) AS ids
FROM users
WHERE email IS NOT NULL AND TRIM(email) != ''
GROUP BY LOWER(TRIM(email))
ORDER BY normalized_email;

Actual output:

This confirms the expected result for the first five categories (rows 1, 2, 3 correctly collapse to one alice@example.com group of 3; BOB@EXAMPLE.COM and carol@example.com are correctly left alone; NULL and '' are correctly excluded by the WHERE clause rather than silently grouped together) and PROVES the Unicode gap: rows 8 and 9 are the same visual email address but land in two separate groups, because LOWER(TRIM()) operates on bytes, not on normalized Unicode form. Fixing this requires normalizing to NFC (or NFD, consistently) at the application layer before the dedup query runs, since standard SQLite has no built-in Unicode normalization function.

Automating setup and teardown: seed the fixture rows above from a versioned SQL or JSON fixture file (not ad hoc INSERTs typed in each test), so the case list is reviewed and diffed like code. Each test should run inside its own transaction: BEGIN, insert fixtures, run the dedup query, assert, then ROLLBACK (or, for engines/frameworks without cheap savepoints, TRUNCATE and re-seed between tests). This keeps the 9-row dataset above isolated per test run so tests can execute in parallel and in any order without one test's leftover rows corrupting another's expected row_count.

Trade-offs and pitfalls
The most common pitfall is writing the dedup query, seeing it pass on a small hand-built dataset, and never testing a genuine Unicode-normalization collision, because NFC and NFD variants of the same string look byte-identical when eyeballed in a terminal or spreadsheet. A second pitfall is treating NULL and '' as the same case: they require different WHERE/COALESCE handling and different product decisions (is a blank email a data-quality bug to flag, or a legitimately unset optional field to ignore?). Finally, resist "fixing" the Unicode gap by adding a COLLATE NOCASE-style trick in SQL: collations control comparison behavior, not byte-level Unicode normalization, so that only strengthens the casing case, not the NFC/NFD case; the real fix is normalizing at the application or ETL layer with a Unicode-aware library before the row ever reaches this query.

Direct answer

A cross-team initiative I was part of missed its goals because of how, not what, we coordinated: unclear ownership across the teams involved, and assumptions that stayed unstated until they caused real problems. The lasting change wasn't a one-time apology or a single retro action item; it was a concrete shift in how the teams handed work to each other afterward, and I could point to whether that same failure mode recurred as the real evidence it stuck.

Structured elaboration

What broke, specifically

Swap in whatever cross-team dependency applies in your own world (a shared data pipeline, an API contract, a joint launch). In this skeleton, a project spanning several teams missed its deadline and caused repeated problems during a pilot phase because of two gaps: an unstated assumption about how a downstream team's dependency actually worked, and no clear escalation path when a blocking issue crossed a team boundary, so problems sat for days before the right people even knew about them.

How I ran the postmortem

• Built a timeline from evidence (incident counts, missed dates, rollback frequency), not memory or opinion.
• Separated the technical root causes from the collaboration root causes, since they needed different fixes.
• Named my own part in the failure to the group first, rather than only pointing at others' misses.

What actually changed afterward, and how I know

Concrete artifacts, not intentions: a documented dependency map required before a cross-team project kicks off, a clear ownership assignment per milestone naming who is accountable for what, and a pre-cutover checklist signed off by every team with something at stake, not just the owning team.

When the real obstacle is culture, not process

Sometimes the harder problem isn't a missing checklist, it's shifting a broader culture away from punitive postmortems toward ones people are actually honest in, particularly when some teams still default to blame. Modeling that shift means naming your own contribution to the failure before asking anyone else to, keeping the review focused on the system and the decision points rather than individuals, and treating a later postmortem where someone from a still-blame-oriented team volunteers a candid mistake as the real signal that the culture is moving, not just a nice-to-have.

Worked example

A multi-team initiative to consolidate several systems onto a shared platform missed its timeline and caused a string of problems during a pilot rollout. The retro traced the root cause to two things: application teams weren't told about a change in how long access credentials would remain valid under the new platform, and there was no agreed escalation path when a blocking issue spanned two teams. The concrete changes that came out of it were a mandatory dependency map and sign-off checklist before any team's cutover, and a named escalation contact per team for the duration of the rollout. A better signal of real progress on culture came from a smaller moment: at the next postmortem, a team that had previously stayed quiet about its own mistakes volunteered, unprompted, that a missed step on their side had contributed to a separate incident, which said more about the blame reflex fading than anything written in a process document.

Trade-offs and pitfalls

• A postmortem that produces only reflections ('we should communicate better') without a concrete, checkable change is the most common failure of this kind of story; the interviewer is listening for what's different in the next project, not what was learned.
• Owning your own part in the failure has to be genuine, not a rhetorical move before pivoting to blame others; if it reads as performative, it undercuts the whole story.
• A culture shift away from blame doesn't happen from one retro; it shows up gradually, in whether people volunteer uncomfortable information without being asked, and that takes sustained modeling, not a single well-run session.
• Watch for a story that only describes what changed for the team that failed, rather than what changed structurally for how all the involved teams hand off work to each other, since the initiative broke because more than one team was involved.

Direct answer. For a legacy product whose front-end DOM/CSS changes frequently, the fix is rarely "write more resilient Selenium" - it's narrowing what the UI layer is actually responsible for testing, choosing locators that survive structural churn, and shifting coverage that doesn't genuinely need a real browser down to a faster, more stable layer (component or API tests).

Structured elaboration.

• Test scope: reserve true UI/E2E tests for what can ONLY be verified through a real rendered browser (visual layout, genuine cross-component interaction, real user-perceivable behavior); push everything else (business logic, validation rules, data transformations) down to unit or API-level tests that don't touch the fragile DOM at all.
• Selector strategy: prioritize STABLE attributes over structural ones - data-testid (if you can get it added to the markup) beats a positional CSS selector, which beats an XPath keyed to exact DOM nesting; if you cannot change the markup at all (a truly legacy, unowned front-end), prefer text-based or ARIA-role-based locators over deep structural paths, since text/role tends to survive markup churn better than nesting depth does.
• Abstraction layers: centralize every locator behind a page-object/locator-registry layer specifically so that when the DOM does change, the fix is ONE edit to the registry, not a hunt through every test file.
• Alternatives - component or API testing: for logic that's technically reachable through the UI but doesn't need to be verified THROUGH it, a component test (rendering just the piece in question, if the front-end framework supports isolated component testing) or a direct API test is both faster and immune to unrelated DOM churn elsewhere on the page.

Worked example. A concrete reprioritization: a checkout page's discount-calculation logic is currently verified only via a full E2E test that fills out the whole cart flow - moving that specific assertion to an API-level test (call the pricing endpoint directly with the same inputs, assert the same expected total) removes it from the fragile-UI blast radius entirely, while a MUCH smaller, targeted E2E test remains just to confirm the discount actually RENDERS correctly on the page for the user, which is the one thing only a real browser test can verify.

Trade-offs and pitfalls. Retreating from UI testing HAS to be a considered trade, not a total abandonment - moving too much coverage down to API/unit level can leave the actual user-visible rendering under-tested, so a real production bug (a discount that calculates correctly but displays wrong due to a front-end bug) can ship undetected if nothing still exercises the real page.