21 Selenium 4 Migration and Framework Evolution Interview Scenarios

Selenium migration is risk management with code attached. A dependency update may compile while capability negotiation, Grid routing, waits, browser provisioning, or report integration changes underneath it. Senior engineers begin by identifying constraints and observable contracts, then move one boundary at a time with a removal plan for every temporary adapter.

These scenarios are designed for framework owners, not candidates reciting renamed methods. Each answer should explain how to establish evidence, limit the change surface, compare old and new execution, and decide when the legacy route is safe to delete.

Build a Migration Control Loop

The official upgrade guide covers dependency updates, standards-compliant capabilities, options, and binding deprecations. Treat it as an input to a repository-specific inventory: the actual risk lies in how your framework wrapped those APIs and how remote infrastructure interpreted them.

Every compatibility layer needs an owner, a metric, and a deletion condition. Without those, "incremental migration" becomes permanent duplication.

Inventory and Baseline Scenarios

1. Why should migration start with a call-site and runtime inventory?

Dependency files reveal only declared versions. Search for driver constructors, DesiredCapabilities, raw capability maps, old element helpers, custom waits, Grid URLs, CDP calls, static driver access, and report listeners. Then observe which paths execute in CI. An unused deprecated helper is deletion work; a hidden reflection-based factory is migration risk. Rank items by workflow criticality and blast radius.

2. How would you create a trustworthy pre-migration baseline?

Select deterministic smoke and high-risk workflows, fix their test data, and record requested plus negotiated capabilities, failure categories, queue time, command time, artifacts, and cleanup. Run enough repetitions to expose known instability without inventing a universal threshold. The baseline is evidence for comparison, not a claim that every existing failure is acceptable.

3. Why is a single big-bang branch hard to validate?

It combines binding APIs, session negotiation, Grid topology, browser images, waits, and framework design. A failure then has many plausible causes, and rollback discards unrelated improvements. Stage dependency and compile changes, local session construction, remote negotiation, Grid routing, and framework cleanup. Keep each step releasable or protected by an explicit short-lived route.

Dependency and Capability Scenarios

4. How would you upgrade Selenium dependencies without introducing binding conflicts?

Inspect the resolved dependency graph, not only the direct package declaration. Align Selenium modules to the binding's supported release set, remove obsolete standalone artifacts, and check runner, reporting, and remote-provider integrations. Compile first, then run a session handshake in every supported language module. Excluding transitive packages blindly can produce runtime method errors that compilation in another module misses.

5. Why should DesiredCapabilities construction move to browser-specific options?

Options classes are the supported binding abstraction for browser arguments, preferences, proxies, timeouts, and capability merging. Build a common target model, then translate it into ChromeOptions, FirefoxOptions, or the corresponding binding type. Tests should not edit arbitrary maps. Keep cloud-provider values namespaced and isolated so standard capabilities remain valid for local and Grid execution.

6. How would you handle an old Grid capability that is not W3C-compliant?

Determine whether it represents a standard capability, a provider extension, or obsolete metadata. Convert standard meaning to the correct name and type; place legitimate provider data under its namespaced container; remove values used only by the old router. Do not pass unknown top-level keys and hope the server ignores them. Add a negotiation test that inspects the returned session capabilities.

ChromeOptions options = new ChromeOptions();
options.setPlatformName("linux");
options.setCapability("vendor:options", Map.of("build", buildName));
WebDriver driver = new RemoteWebDriver(gridUrl, options);

Binding API Scenarios

7. Why should deprecated API replacement preserve behavior rather than only compilation?

Two methods with similar names may differ in exceptions, return values, timeout units, or whether lookup is immediate. Write a characterization test around the wrapper before replacement, then exercise success, absence, stale elements, and remote failure. Compilation proves type compatibility; it does not prove the same product state is observed or the same diagnostics reach the report.

8. How would you migrate timeout configuration safely?

List implicit, page-load, script, explicit-wait, runner, and session-acquisition timeouts separately with their units and owners. Convert them into typed durations at one configuration boundary. Then test each timeout intentionally. A broad numeric constant can silently change meaning across binding APIs. Avoid increasing all budgets to hide one newly exposed wait or Grid queue problem.

9. Why should an Actions migration be validated on the real interaction sequence?

Composite keyboard, pointer, and wheel behavior depends on input source state, element coordinates, focus, and the final perform command. Rebuild the sequence with the current Actions API and assert the user-visible result, not merely that no exception occurred. Cover drag, modifier release, scrolling, and cleanup of input state where the suite relies on them across browsers.

Grid Architecture Scenarios

10. Why must a Grid upgrade plan describe components instead of saying "replace the hub"?

Grid architecture separates responsibilities such as the New Session Queue, Distributor, Nodes, Session Map, Router, and Event Bus. The official Grid architecture guide explains how session requests are queued and assigned to node slots. Deployment, health, logs, and capacity decisions should follow those roles even when a simple mode runs them together.

11. How would you validate session routing after moving to the new Grid?

Send controlled requests for each supported browser and platform combination, capture queue and distributor decisions, and compare negotiated capabilities with the requested contract. Confirm the selected node can launch the browser and that commands continue through the router for the life of the session. A green Grid status page does not prove stereotype matching or end-to-end routing.

12. Why should a team begin with a simple Grid topology before distributing every component?

A standalone or less distributed deployment can establish capability matching, browser images, authentication, observability, and client compatibility with fewer network boundaries. Split components only for measured scale, resilience, or operational needs. Starting at maximum topology makes routing, event-bus, and datastore issues indistinguishable from binding migration problems and raises rollback complexity.

Framework Evolution Scenarios

13. How would you migrate page objects that expose WebDriver everywhere?

Introduce domain methods and component boundaries around the most volatile workflows while preserving a compatibility facade for current tests. Move locators and synchronization behind those methods, return typed evidence, and migrate callers incrementally. Do not redesign every page during the dependency upgrade. The adapter should shrink measurably and prohibit new raw-driver access.

14. Why is a compatibility wait helper useful only with an expiration plan?

It can translate old call sites to a new explicit-wait primitive while reducing one migration step. But if it accepts arbitrary locators, sleeps, and ignored exceptions forever, the old semantics remain. Mark migrated consumers, add diagnostics that identify remaining calls, and delete the helper once named domain waits cover them. Compatibility should reveal debt, not conceal it.

15. How should shared driver state be treated during migration?

Make isolation a separate acceptance criterion. Replace static or suite-wide drivers with per-test ownership behind a temporary accessor if changing every signature at once is impractical. Add a guard that rejects access outside an active invocation and run parallel probes. A new binding on top of shared state preserves the most damaging framework risk even if APIs are current.

Dual-Run Evidence Scenarios

16. How would you run old and new paths without letting them mutate the same test data?

Assign separate accounts or namespaces to each path and feed both the same immutable scenario inputs. Compare normalized outcomes afterward. Running two browsers against one order can create differences caused by competing writes rather than migration. The dual-run harness must label path, session, environment, and data identity so evidence remains attributable.

17. Why should dual-run comparison focus on contracts instead of identical logs?

Grid components, protocol messages, and binding stacks naturally differ. Compare whether the right browser was negotiated, the same user outcome occurred, required network or console evidence was captured, failures were classified, and resources were released. Normalize volatile ids and timestamps. Log equality rewards implementation similarity rather than preserved test coverage and behavior.

18. How would you define rollback criteria for a staged migration?

Name mandatory workflow failures, session-start error categories, unsupported capability combinations, data corruption, artifact loss, and cleanup leaks that trigger rollback. Also define who decides and how traffic returns to the old path. A small increase in duration may prompt investigation rather than rollback, while silent loss of a required assertion should stop the stage immediately.

Legacy Removal Scenarios

19. Why should the old adapter be deleted soon after the new path proves stable?

Two paths double test and operational burden, allow behavior to diverge, and encourage new callers to choose the familiar route. Once the observation window and rollback conditions are satisfied, remove the flag, implementation, dependencies, configuration, and dead tests in one reviewed change. Keep migration evidence in documentation; do not keep executable legacy as a souvenir.

20. How would you update team practices so the framework does not regress?

Revise examples, code templates, review checks, runbooks, and ownership maps to show options-based session creation, isolated drivers, current Grid diagnostics, and approved BiDi or CDP boundaries. Add static checks for forbidden imports or capability builders where practical. Training should use real failure cases from the migration so engineers understand why the new constraints exist.

21. Why is "all tests pass" insufficient as a migration completion rule?

Tests may pass while an unused old route, duplicate dependencies, silent capability fallback, missing artifacts, or orphan sessions remain. Completion requires every supported lane on the new path, negotiated contracts verified, operational dashboards and runbooks updated, rollback debt closed, and legacy code removed. Passing scenarios are necessary evidence, but framework and operational cleanup finish the migration.

Migration Review Checklist

• Inventory runtime call sites, topology, capabilities, data ownership, and integrations.
• Establish deterministic outcome and diagnostic baselines before changing paths.
• Replace loose capabilities with validated options and namespaced extensions.
• Stage binding, Grid, and framework redesign so each cause set stays reviewable.
• Dual-run on separate mutable data and compare normalized behavior contracts.
• Give every adapter a named owner, usage signal, and deletion condition.
• Remove old flags, dependencies, configuration, and runbooks after proof.

Conclusion: Finish by Removing the Bridge

A disciplined Selenium 4 migration moves from known constraints to bounded changes and evidence. It validates new-session negotiation, Grid routing, domain behavior, diagnostics, and cleanup independently enough to explain failures. The work is complete only when the new path stands alone and the temporary bridge is gone. Anything less is coexistence, not evolution.