You inherit a 600-test end-to-end suite whose selectors are a mix of XPath, hashed CSS class names and ad-hoc test ids, and it breaks on most user-interface pull requests. How would you move it to one selector convention without freezing feature work?

## Frame the problem correctly first This is not flakiness. A flaky test passes and fails on the same code; this suite fails **deterministically** because the app changed shape. That distinction matters because it rules out the tempting non-fix: adding retries. Retrying a selector that no longer matches burns CI time and delays the same red. Say that explicitly — an interviewer is listening for whether you can tell breakage and flake apart. It is also not primarily a test problem. Most of the fix lives in the application: controls that are real, labelled controls, and components that render entity-scoped test ids. A migration plan that assigns all the work to whoever owns the test suite will stall. ## Step 1: get evidence before you get opinions Run a short diagnostic before proposing anything: - Pull failures from the last few weeks of CI and classify them by cause: selector no longer matches, timing, data, genuine regression. - Attribute the selector failures by style (XPath, generated class, text, test id) and by spec and screen. - Count how many pull requests were blocked, and how much developer time went into re-running or patching. The usual finding is a heavy concentration: a minority of specs, hitting a minority of screens, cause most of the breakage — commonly the screens under active redesign. That concentration is the plan. It also gives you the business case, expressed in blocked pull requests rather than in taste. ## Step 2: write the convention down One page, unambiguous, with the ladder and the escape hatch: 1. Accessible role and name for anything a user identifies by what it is and what it says. 2. A component-owned `data-testid` where identity is not user-perceivable, or where it identifies an instance (`order-row-1042`). 3. Structural CSS only inside third-party markup, with a comment saying why. Include naming rules for test ids, the container-scoping pattern, and the locale decision for text matching. Ambiguity in the document becomes inconsistency in the suite. ## Step 3: stop the bleeding before cleaning up Migration fails when the old style keeps arriving. Two gates: - **Mechanical where possible.** A lint rule banning XPath helpers and selectors that look like generated class hashes catches most new violations cheaply and impersonally, which matters more than catching all of them. - **Boy-scout rule.** Any spec a pull request touches must be brought to the convention. This spreads cost across the teams causing the churn, and it naturally prioritises the files that change most. Apply the gates to new code only, so the existing 600 do not block anyone on day one. ## Step 4: migrate in funded slices, app first Take the top offenders from step 1 and work screen by screen, not spec by spec: fix the screen's markup — real buttons, real labels, entity-scoped test ids on list rows — then re-anchor every spec that touches it. Screen-level batches keep the app work coherent and let one component change fix a dozen tests. Ship each slice separately so value lands continuously, and pair with the team that owns the screen so the labels land with product context rather than as a drive-by patch. Expect to delete as well as migrate. A suite that size usually contains duplicates and tests better served at a lower level; migration is a reasonable moment to ask whether a given test earns its runtime at all. Be careful this does not become an excuse to drop coverage — decide by what the test protects, not by how annoying it is to fix. ## Step 5: measure the outcome, not the activity "78% of specs migrated" is an activity metric and can reach 100% while pull requests still break. Track instead: - share of pull requests whose only failures are non-behavioural test breakages, - mean time from red to green on those, - number of new selector-caused failures per week. When those numbers stop moving, the remaining specs are not worth migrating, and you say so and stop. Knowing where to stop is part of the answer. ## The organisational half The convention survives only if ownership is clear: component owners own the test ids and labels their components render, the platform or quality group owns the document and the lint rule, and removing a test id is reviewed like removing public API. Left ownerless, the suite drifts back to XPath within two quarters — usually via a recorder, because recorders emit exactly the brittle style you just removed. If the team uses one, constrain how its output is allowed to be committed.