Selenium Interview Questions

Selenium WebDriver, the core component for actually automating browser actions through code. Selenium IDE, a browser extension for recording and playing back simple test scripts without writing code directly. Selenium Grid, used for running tests across multiple machines and browsers at the same time, in parallel.

WebDriver is a programming library you use directly in code, in Java, Python, or another supported language, giving full control and flexibility over test logic. IDE is a browser extension that records your actual clicks and interactions and plays them back, which is faster for a quick, simple test but far less flexible than writing genuine code.

Selenium supports all the major browsers, Chrome, Firefox, Edge, Safari, through a dedicated browser driver specific to each one, ChromeDriver for Chrome, GeckoDriver for Firefox. That driver acts as the actual bridge between your test code and the real browser, translating your Selenium commands into the browser's own native automation protocol.

A browser driver is a separate executable that Selenium communicates with, which then directly controls the actual browser on your behalf. It's needed because Selenium itself doesn't know how to control a specific browser directly, it delegates that actual work to the browser-specific driver, which understands that particular browser's own native automation interface.

Selenium is the older, most widely established tool, supporting the broadest range of languages and browsers, and it's genuinely mature with a large ecosystem behind it. Cypress and Playwright are newer tools, generally faster and offering better built-in handling of waiting for elements, but each with its own trade-offs, like Cypress historically working only within a single browser tab.

WebDriver driver = new ChromeDriver(); creates a new instance of ChromeDriver, which actually opens a fresh Chrome browser window ready for your test code to control. The equivalent exists for each other supported browser, using its own specific driver class.

driver.get('https://example.com'); opens that URL directly in the currently controlled browser window and waits for the page to actually finish loading before the next line of code runs.

Both ultimately navigate the browser to the specified URL. navigate().to() is part of Selenium's broader Navigation interface, which also provides additional methods like back(), forward(), and refresh(), while get() is a simpler, more direct method that just does the navigation itself without that extra surrounding interface.

driver.close() closes just the current browser window or tab the driver is actively focused on. driver.quit() closes every single window the WebDriver session opened and properly ends the entire WebDriver session itself, which is generally what you want to call at the actual end of a test to clean up completely.

WebDriver is an interface defining a common, standard set of methods every browser-specific driver, ChromeDriver, FirefoxDriver, must actually implement. Using an interface lets your test code work against that same shared, common contract regardless of which specific browser you're actually running against, so switching browsers doesn't require rewriting your actual test logic.

A WebElement represents a single element on a web page, a button, an input field, a link, that Selenium found and can now interact with. You get one by locating it, using findElement(), and then call methods on it directly, like click() or sendKeys().

Locators are strategies for finding a specific element on a web page, by ID, by class name, by an XPath expression, and several others. They're needed because Selenium has to precisely identify exactly which element on the page you actually want to interact with before it can click it, type into it, or read its text.

An ID is meant to be unique to a single element on a page, so By.id() reliably finds exactly one specific element. A class name is often shared across multiple elements on the same page, so By.className() can return several matches, and using findElement() (which returns just the first match) on a shared class name might not actually return the specific element you genuinely intended.

XPath is a query language for navigating and selecting elements within an XML (or HTML) document's structure. //button[@id='submit'] is an XPath expression finding a button element with a specific id attribute. It's flexible enough to locate an element based on its actual text content, its position, or its relationship to other elements, which simpler locators genuinely can't always express.

An absolute XPath starts from the document's root and specifies the complete, exact path to an element, like /html/body/div/form/button. It's fragile, breaking the moment the page's overall structure changes even slightly. A relative XPath starts with //, and can locate an element anywhere on the page matching a given pattern, which is far more resilient to minor structural changes elsewhere on the page.

CSS selectors use the same syntax used for styling a page, like #id, .class, or a combination like div.container > button, to locate an element. They're generally faster than XPath and often more readable for simple cases, though XPath can express certain relationships, like finding a parent based on its child, that a CSS selector genuinely can't express on its own.

findElement() returns the first single matching element it finds, and throws a NoSuchElementException if absolutely nothing actually matches. findElements() returns a list of every matching element found, or an empty list if nothing actually matches, without throwing an exception at all.

driver.findElement(By.id('submit')).click(); locates the element by its ID first, then calls click() on the WebElement that was actually returned, simulating a genuine mouse click on that specific element.

driver.findElement(By.id('username')).sendKeys('testuser'); locates the input field and types the given text into it, character by character, exactly as if a real user had actually typed it themselves.

driver.findElement(By.id('username')).clear(); removes any existing text currently in the field. It's commonly called right before sendKeys() to ensure the field genuinely starts empty, rather than accidentally appending new text onto whatever was already sitting there from before.

driver.findElement(By.id('message')).getText(); returns the element's actual, currently rendered, visible text content as a string, which you can then use for an assertion or simply print for debugging purposes.

driver.findElement(By.id('banner')).isDisplayed(); returns true if the element is genuinely visible on the page, and false if it exists in the DOM but is actually hidden, through CSS, for example, or simply not present on the page at all.

driver.navigate().back(); simulates clicking the browser's own back button. driver.navigate().forward(); simulates clicking forward. Both work with whatever browsing history already exists for that specific browser session.

A modern web page often loads content asynchronously, through JavaScript, after the initial page itself has already loaded. Without a wait, Selenium might try to interact with an element before it's actually present or fully ready on the page yet, causing the test to fail even though the element would have genuinely appeared correctly just a moment later.

driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)); tells Selenium to wait up to that specified time for an element to actually appear before throwing a NoSuchElementException, applied automatically across every single findElement() call for the entire duration of that WebDriver session, without you needing to repeat it individually for each one.

Mixing the two can produce genuinely unpredictable, inconsistent wait times, since the actual behavior can vary depending on the specific driver and version being used, sometimes summing the two waits together, sometimes not. Most established best practices recommend consistently using just one wait strategy, generally explicit waits, throughout an entire test suite rather than genuinely mixing both together.

An implicit wait polls repeatedly and proceeds the moment the element actually appears, up to the specified maximum. Thread.sleep() pauses execution for the exact, full duration specified every single time, regardless of whether the element genuinely appeared much sooner, which makes tests unnecessarily and needlessly slower overall.

It pauses the test for a fixed amount of time no matter what, which either wastes real time if the element actually appeared much sooner, or still genuinely fails the test if the element happens to take longer than that fixed, hardcoded delay to actually appear. A proper wait strategy adapts dynamically to how long the page genuinely takes, rather than guessing at a single fixed number upfront.

TestNG is a testing framework for Java, providing annotations like @Test and @BeforeMethod, assertions, and test reporting. It's not part of Selenium itself, but it's commonly used together with Selenium to actually structure and organize automated browser tests, handle setup and teardown, and generate a readable, structured test report at the end.

@BeforeMethod runs before every single individual test method in the class, commonly used to open a fresh browser for each and every test. @BeforeClass runs only once, before any of the test methods in that class actually start running, commonly used for a genuinely one-time setup step that every test in the class can then safely share.

Assert.assertEquals(actualText, expectedText); compares two values and fails the test with a clear, descriptive message if they genuinely don't match. Assertions are how a test actually verifies the application behaved correctly, rather than just running through the motions without ever actually checking anything at all.

A hard assertion stops the test immediately the moment it fails, and any code after that specific point never actually runs at all. A soft assertion records the failure but lets the test genuinely continue running, with every recorded failure only reported together at the actual end, useful when you want to check several independent things in one single test without stopping at the very first failure encountered.

A test suite groups multiple related test classes or methods together, letting you run them all together as one single, larger unit rather than running each individual test file separately by hand. In TestNG specifically, this is commonly configured through an XML file defining exactly which test classes belong in that specific suite.

Reusing a session across tests can let leftover state, like cookies or an item already left sitting in a shopping cart, from one test unintentionally affect the very next test's actual result, making test failures genuinely harder to trace back to their true, actual root cause. Starting each test from a clean, fresh state keeps tests properly independent and their results far more genuinely reliable and trustworthy.

//button[contains(text(), 'Submit')] finds a button whose visible text contains the substring Submit anywhere within it, rather than requiring the button's text to match that exact string in full, which is genuinely useful when a button's text might include additional dynamic content alongside that fixed core label.

Look for a different, genuinely stable attribute to anchor the locator to instead, like a data-testid attribute specifically added for testing purposes, or a stable, unique combination of the element's actual text content and its position relative to other nearby elements. Relying on a dynamically generated ID or class name for a locator will inevitably and predictably break the very next time the page happens to regenerate it.

contains() matches if the specified substring appears anywhere at all within the target attribute or text. starts-with() matches only if the target attribute or text genuinely begins with that specified substring. starts-with() is particularly useful for an ID that has a stable prefix but ends with a dynamically generated, unpredictable suffix each time the page loads.

CSS selectors are generally faster and more readable for straightforward cases, like locating by ID, class, or a simple, direct attribute value. XPath becomes genuinely necessary once you need to locate an element based on its own visible text content, navigate to a parent from a child, or express a more complex relationship between elements that CSS selectors simply can't express on their own.

An explicit wait, using WebDriverWait, waits for a specific, defined condition to actually become true before proceeding, like an element becoming clickable, applied only to that one specific line of code rather than globally across the entire session. An implicit wait instead applies the exact same fixed timeout globally to every single findElement() call throughout the whole session, with no way to wait for a different, more specific condition beyond an element's mere presence.

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10)); wait.until(ExpectedConditions.elementToBeClickable(By.id('submit'))).click(); waits up to ten seconds for the specified element to genuinely become clickable, then clicks it the moment that condition is actually satisfied.

visibilityOfElementLocated() waits for an element to become visible. elementToBeClickable() waits for an element to be both visible and genuinely enabled for interaction. presenceOfElementLocated() waits only for an element to exist in the DOM at all, without any requirement that it actually be visible on the page yet.

A fluent wait lets you configure both the polling interval, how frequently the condition is actually rechecked, and specify which particular exceptions to genuinely ignore while actively waiting, like NoSuchElementException, offering more fine-grained control than a standard explicit wait's default behavior. It's useful for a genuinely tricky element that might briefly and repeatedly appear and disappear from the DOM while the page is still actually settling and finishing its rendering.

Wait explicitly for the specific overlay or spinner element to actually disappear first, using invisibilityOfElementLocated(), before attempting to interact with the actual element genuinely underneath it. Attempting to click an element that's currently covered by something else typically throws an ElementClickInterceptedException, even though the target element does technically exist in the DOM at that exact moment.

The Select class wraps a standard HTML <select> element. Select dropdown = new Select(driver.findElement(By.id('country'))); dropdown.selectByVisibleText('India'); selects a specific option by its actual visible, displayed text. You can also select by its underlying value attribute or by its numeric index instead.

Calling click() on the checkbox's WebElement toggles its current state. Since click() simply toggles it either way, checking the checkbox's current state first with isSelected() before clicking avoids accidentally toggling it into the wrong, unintended state if the test happens to run against a checkbox that's already checked.

driver.switchTo().alert() switches WebDriver's actual focus to the currently open alert. From there, accept() clicks OK, dismiss() clicks Cancel, and getText() reads the alert's actual displayed message. A regular findElement() call genuinely can't interact with a native browser alert at all, since it exists outside the actual page's DOM entirely.

driver.getWindowHandles() returns the unique handles for every currently open window or tab. driver.switchTo().window(handleId) switches WebDriver's actual focus specifically to the window matching that particular handle. Selenium can only genuinely interact with whichever single window currently holds its actual focus at any given moment.

driver.switchTo().frame('frameName') (or the frame's index, or a WebElement reference to it) switches WebDriver's focus specifically into that iframe first. Elements inside an iframe genuinely aren't accessible directly until you've explicitly switched into that frame, and driver.switchTo().defaultContent() switches back out to the actual main page afterward.

POM organizes test code by creating one dedicated class per page (or component), with that class holding the page's own locators and the specific action methods for interacting with it. It solves the real problem of a locator changing and forcing you to hunt down and update it in dozens of scattered test files, since with POM that specific locator now exists in genuinely exactly one single place.

A LoginPage class would hold WebElement locators for the username field, password field, and login button, plus methods like login(username, password) that internally handles typing into each field and clicking the button. Test code then simply calls loginPage.login('user', 'pass') directly, without ever needing to know or care about the actual underlying locators used behind that method.

Data-driven testing runs the exact same test logic repeatedly, but with different sets of actual input data each time, commonly pulled from a CSV file, an Excel sheet, or a database. It avoids writing a nearly identical, separate, and redundant test method for every single different combination of input data you genuinely need to verify.

The @DataProvider annotation defines a method that supplies an array of different data sets. A test method annotated with @Test(dataProvider = 'providerName') then automatically runs once, separately, for each individual data set the provider actually returns.

driver.manage().window().maximize(); resizes the browser window to fill the entire available screen. This is commonly called right at the very start of a test, since some elements can behave, or even render, genuinely differently at a smaller, non-maximized window size.

TakesScreenshot screenshot = (TakesScreenshot) driver; File src = screenshot.getScreenshotAs(OutputType.FILE); casts the driver to the TakesScreenshot interface, then captures the current browser view as an actual image file, commonly saved automatically whenever a test genuinely fails, to help with debugging exactly what went wrong afterward.

If the upload uses a standard HTML <input type='file'> element, sendKeys() with the actual, full file path works directly, since Selenium simulates typing that exact path straight into the file input, without ever needing to interact with the operating system's own native file picker dialog at all.

driver.get() navigates the current, existing tab to a genuinely new URL. Opening a new tab requires executing JavaScript, or simulating a specific keyboard shortcut, to actually create it, and then explicitly switching WebDriver's focus to that specific new tab's window handle before you can interact with anything on it at all.

Page Factory uses the @FindBy annotation to declare locators, and initElements() then initializes those specific WebElements automatically, rather than manually calling findElement() by hand inside every single individual method the way plain POM typically does. It also enables lazy initialization, meaning an element genuinely isn't actually located until the specific moment it's actually used, rather than when the page object itself is first constructed.

BDD writes test scenarios in a structured, plain-language format, Given-When-Then, that's genuinely readable by non-technical stakeholders like a product manager or a business analyst, beyond just the engineers writing the actual code. Cucumber parses that plain-language scenario and maps each individual line to actual step-definition code, which then internally calls Selenium to genuinely perform the described browser actions.

Externalize test data into configuration files, a database, or an API, rather than hardcoding it directly inside individual test methods. This makes updating test data significantly easier without touching any actual test code, and it also allows the exact same test suite to run reliably against different environments, like a staging environment versus production, using genuinely different data sets for each one.

TestNG's IRetryAnalyzer interface lets you automatically retry a specific failed test a defined number of times before genuinely marking it as an actual failure. This is a reasonable, pragmatic short-term mitigation for a test that's genuinely flaky due to timing issues, but it shouldn't be treated as a permanent substitute for actually fixing the real, underlying cause of that flakiness.

A hard-coded Thread.sleep() represents the least mature, most brittle approach, guessing blindly at a fixed delay. An implicit wait is a meaningful step up, adapting somewhat but applying the exact same fixed timeout indiscriminately everywhere. A custom fluent wait, tailored to the specific condition genuinely being waited for, represents the most mature, deliberate, and reliable approach, and is what a well-designed framework should consistently rely on throughout.

JavascriptExecutor lets you directly execute arbitrary JavaScript code within the context of the current page, used for things Selenium's own standard API genuinely can't do directly, like scrolling a specific element into view, or clicking an element that's technically present but not currently interactable through Selenium's normal, standard click() method.

((JavascriptExecutor) driver).executeScript('arguments[0].scrollIntoView(true);', element); runs the browser's native scrollIntoView method directly on the specified element, bringing it into the currently visible viewport, which is commonly needed before interacting with an element that currently sits well below the fold.

The Actions class builds and then performs more complex user interactions, like a mouse hover, a drag-and-drop action, or a right-click context menu, none of which a plain, standard click() call is actually capable of expressing or performing on its own.

new Actions(driver).dragAndDrop(sourceElement, targetElement).perform(); simulates pressing down on the source element, dragging it, and releasing it directly onto the target element, all combined together in one single, complete, chained action.

Newer versions of Selenium provide a getShadowRoot() method directly on a WebElement, letting you search specifically within that shadow root once you've actually located its genuine host element first. Without that specific, dedicated support, a standard locator simply can't reach elements that are genuinely nested inside a shadow root at all.

A StaleElementReferenceException happens when an element you previously located gets removed from or replaced within the DOM before you actually try to interact with it again. Handling it properly typically means re-locating the element fresh right before each individual interaction, rather than caching a single WebElement reference and reusing that exact same cached object repeatedly across multiple, separate actions.

Ensure each individual test creates and uses its own completely independent WebDriver instance rather than ever sharing one single driver across multiple parallel tests, and avoid relying on any genuinely shared, mutable state, like a shared, static test data object, that multiple tests might otherwise read or modify concurrently at the very same time.

The pipeline triggers the test suite to run automatically on a schedule, or immediately following a new deployment, typically running headless (no visible browser UI actually needed) inside the CI environment for genuine speed and efficiency. Test results then get published in a format the pipeline can automatically parse, failing the overall build outright if a genuinely critical test actually fails.

Headless testing runs the actual browser without rendering any visible UI at all, which is generally faster and uses meaningfully less resources, making it well suited for a CI environment running many tests. The trade-off is that certain visual or genuinely rendering-specific issues might not surface the exact same way they would in a real, fully visible browser, and debugging a test failure is somewhat harder without being able to actually watch it visually run in real time.

Automatically capture a screenshot at the exact moment of failure, log the specific step and locator that was actually involved, and generate a structured, readable report, using a tool like Extent Reports or Allure, rather than relying purely on a raw console log output that's genuinely hard to scan quickly through for dozens or hundreds of individual test results.

Externalize environment-specific values into separate configuration files or environment variables, selected at actual runtime based on which specific environment the suite is currently being run against, rather than hardcoding a URL directly inside the test code itself, which would otherwise require actually editing the code itself every single time you needed to genuinely switch environments.

Automate tests that are genuinely repetitive, stable, and run frequently, like core smoke tests executed on every single build, since those provide the clearest, most obvious ongoing return on the investment of actually automating them. Tests that are exploratory in nature, genuinely change frequently, or require real, actual human visual judgment, evaluating whether something simply looks right, are usually better left as manual testing instead.

Selenium Grid distributes test execution across multiple machines and browsers, letting you run tests in parallel rather than one strictly after another in sequence. It solves the real problem of a large test suite taking an impractically long time to run sequentially, and lets you genuinely verify an application's behavior across several different browser and operating system combinations at the very same time.

The hub is the central point that receives incoming test requests and routes each one to an available, appropriate node. A node is an actual individual machine (or a container) that genuinely runs the browser and actually executes the test. A single hub can coordinate and distribute work across several different nodes running simultaneously.

Docker containers can each run an individual Selenium node preconfigured with a specific browser already installed, letting you spin up and tear down nodes on demand quickly, rather than manually configuring and maintaining a fixed set of dedicated physical or virtual machines by hand. This also makes it noticeably easier to scale the total number of available nodes up or down based on actual current, real demand.

These services provide access to a genuinely large matrix of real browsers, real devices, and real operating system combinations without an organization needing to actually maintain that infrastructure themselves. It's often worth the ongoing subscription cost once the actual operational burden and infrastructure cost of self-hosting a comparably broad and diverse Grid setup would genuinely exceed what the service itself actually charges.

Run the full, complete test suite against the primary, most commonly used browser, and run only a genuinely smaller, carefully chosen, representative subset of critical tests across the additional secondary browsers. Running literally every single test against every single browser combination usually provides real diminishing returns while meaningfully multiplying the actual total execution time many times over.

Confirm it's genuinely a real, actual application bug rather than a Selenium timing or configuration quirk specific to that one particular browser driver, by reproducing the exact same issue manually in that same browser outside of Selenium entirely. Once genuinely confirmed as a real, actual application-level bug, add a targeted, specific regression test for that browser going forward, to actually catch a genuine future recurrence of that same issue.

A version mismatch commonly causes tests to fail with a genuinely confusing session-creation error that has nothing to do with the actual test logic itself. Selenium Manager, bundled with recent Selenium versions, now handles resolving and downloading a matching driver version automatically, which removes most of this specific class of problem, though pinning both the browser and driver versions deliberately in a CI environment still avoids any surprise from an automatic browser update landing mid-pipeline.

Relative locators (above(), below(), toLeftOf(), toRightOf(), near()) let you locate an element based on its visual position on the page relative to another already-located element, without needing a complex XPath expression to express that same spatial relationship. It's useful for a form where a specific input has no unique, reliable attribute of its own, but sits in a visually predictable position relative to a label or another element that does.

Run both the old and new suites fully in parallel for a defined transition period, comparing their actual results directly against each other to genuinely confirm the new suite is truly, reliably catching everything the old one already did, before actually retiring the legacy suite for good. Migrating test by test incrementally, rather than attempting one single, large, disruptive rewrite all at once, keeps genuine coverage intact throughout that whole transition.

I check whether it genuinely separates page-specific logic from reusable, shared core utilities cleanly, whether its actual wait strategy genuinely holds up rather than relying on fragile, hardcoded delays, and whether it's realistically designed to actually scale as both the application itself and the overall test suite continue to grow substantially larger over time.

Automate what can genuinely be automated, code review checks specifically flagging a hardcoded Thread.sleep() or a genuinely fragile, brittle absolute XPath, enforced directly in CI so standards aren't purely a matter of individual opinion during manual code review. For conventions that genuinely resist full automation, I'd document the handful of decisions that actually matter most, along with the real reasoning behind each one.

I'd weigh Playwright's genuinely better built-in auto-waiting and generally faster, more reliable execution against the real cost of a team having to learn new tooling and any existing, working Selenium infrastructure that would otherwise need to be genuinely maintained in parallel during any transition. For a brand new, greenfield project with no existing legacy investment at all, that calculation looks quite different than it would for an organization with years of already-existing, working Selenium tests already in place.

Look first at timing-related issues, an insufficient or genuinely inconsistent wait strategy, since that's overwhelmingly the single most common actual cause of real flakiness in browser-based automation specifically. I'd also check for genuine test interdependence, one test's leftover state unintentionally affecting another test that runs directly after it, and for environment-specific issues that only actually show up under real CI load, but not on a typically much quieter local development machine.

Track pass and fail rates over time per individual test, beyond just an aggregate overall suite-level pass rate, to actually catch a specific test that's becoming genuinely flaky before it starts eroding the whole team's overall trust in the entire suite. I'd also track total suite execution time over time, since a suite that keeps steadily growing slower will eventually become enough of a real bottleneck that people genuinely start skipping or ignoring it out of sheer frustration.

Treat a page object's actual public methods as a genuine contract with every team consuming it. Adding a new method is generally safe. Changing or removing an existing method's actual behavior needs a documented deprecation period and direct, proactive communication with every consuming team, rather than a silent breaking change that quietly and suddenly breaks other teams' tests with no warning at all.

I'd triage each individual failure quickly to distinguish a genuine, real application bug from mere test flakiness, since blocking an entire release over flaky infrastructure rather than an actual real bug is a real, costly mistake in its own right. For any test that's confirmed as genuinely flaky rather than a real failure, I'd fix or genuinely quarantine it rather than simply ignoring it and letting it keep silently eroding trust in the suite going forward.

Parallelize test execution across a Grid or a cloud provider as the very first, most direct lever, since that alone often keeps overall wall-clock execution time roughly flat even as the actual total number of individual tests keeps growing. Beyond that, I'd periodically and genuinely review the suite for redundant or genuinely low-value tests that could safely be trimmed or consolidated, rather than assuming every single individual test that's ever been added is still genuinely worth its own ongoing execution cost.

This is a judgment question interviewers use to see how you reason under genuine uncertainty, not to test a specific textbook fact. A strong answer names the actual constraint that forced the decision, the realistic options that were genuinely on the table, why you picked one knowing it wasn't guaranteed to be right, and what you'd do differently with what you know now.

I'd walk through one of their actual flaky tests together, showing concretely how an explicit wait handles the exact same genuine timing issue more reliably, and often faster too, rather than simply telling them Thread.sleep() is bad practice in the abstract. Seeing their own specific test actually become more reliable in front of them tends to shift that particular habit far more effectively than a general rule ever does on its own.

I wouldn't push a full, disruptive rewrite of everything that already exists. I'd refactor one genuinely painful page, one that keeps breaking repeatedly due to a locator change, into POM as a visible, concrete example, letting the team directly see the real maintenance difference on code they already recognize firsthand, and let that build genuine, organic buy-in rather than mandating the change purely from the top down.

I'd frame it in terms the developers already genuinely care about directly: a stable, dedicated test attribute means fewer flaky test failures blocking their own builds and pull requests, not merely a convenience being asked for purely on the QA team's own behalf. Framing it as a shared, mutual benefit rather than an extra, one-sided favor tends to resolve this kind of disagreement considerably faster.

I'd translate the flakiness into numbers leadership already tracks: hours per week the team spends re-running failed builds or manually verifying a supposedly failed test by hand, and any release that was actually delayed because nobody genuinely trusted the suite's own results anymore. Framed as recovered engineering time and reduced release risk, it competes far better for prioritization than framed as a general test-quality concern.