Sample questions
Ta Synchronization Flaky TestsDifficulty 1
In Selenium WebDriver, what is the main practical difference between an implicit wait and an explicit wait?
- aImplicit wait only works with CSS selectors, explicit wait only works with XPath
- bImplicit wait sets one global timeout for all lookups; explicit wait polls one named condition on one element✓
- cExplicit wait pauses the entire test suite, implicit wait pauses only the current test method
- dImplicit wait is configured individually per element instance, explicit wait is configured once for the entire driver session
Explanation:An implicit wait (driver.manage().timeouts().implicitlyWait(...)) sets a global polling timeout the driver applies to every findElement call, while an explicit wait (WebDriverWait combined with ExpectedConditions) waits for one specific, named condition on one specific element before continuing.
Ta Synchronization Flaky TestsDifficulty 1
What is a "flaky test" in the context of test automation?
- aA test that intermittently passes and fails though the code under test is unchanged✓
- bA test that always fails because the feature it covers was removed
- cA test that runs slower than the team's agreed performance budget
- dA test that is written in an interpreted scripting language instead of a statically compiled one
Explanation:A flaky test passes and fails intermittently against the same code, usually because of timing, environment, or test-isolation issues rather than a real defect, which erodes trust in the suite.
Ta Synchronization Flaky TestsDifficulty 1
Why is mixing implicit and explicit waits in the same Selenium WebDriver script generally discouraged?
- aSelenium raises a compile-time error when both are configured at once
- bExplicit waits silently disable implicit waits for the rest of the session
- cTheir combined timeouts can stack unpredictably, causing some calls to wait far longer than intended✓
- dImplicit waits only take effect after every explicit wait defined anywhere in the script has already completed
Explanation:Because both mechanisms can be in effect simultaneously, a findElement call inside an explicit wait's polling loop can itself be subject to the implicit wait timeout, so the two can stack and produce unexpectedly long or inconsistent waits.
Ta Synchronization Flaky TestsDifficulty 1
In Selenium (Java binding), which line correctly waits up to 10 seconds for an element to become clickable before clicking it?
- adriver.findElement(By.id("submit")).waitUntilClickable(10).click();
- btry { Thread.sleep(10000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } driver.findElement(By.id("submit")).click();
- cdriver.manage().timeouts().pageLoadTimeout(10, TimeUnit.SECONDS);
- dnew WebDriverWait(driver, Duration.ofSeconds(10)).until(ExpectedConditions.elementToBeClickable(By.id("submit"))).click();✓
Explanation:WebDriverWait combined with ExpectedConditions.elementToBeClickable polls until the located element is both visible and enabled, then returns it so .click() can be chained; the other options either use a nonexistent method, a hardcoded sleep, or configure an unrelated page-load timeout.
Ta Synchronization Flaky TestsDifficulty 1
What is generally the biggest problem with using a fixed sleep (e.g. Thread.sleep(5000)) to solve a timing issue in a UI test?
- aIt wastes time when the page is fast, and still fails when the page is slower than expected✓
- bIt is not supported by any modern automation framework
- cIt causes the browser to close before the assertion executes
- dIt only works with Cypress and never with Selenium
Explanation:A fixed sleep guesses a duration: if the real wait is shorter, the test runs slower than necessary; if the real wait is even occasionally longer (slow network, animation, server load), the test still fails, which is why explicit condition-based waits are preferred.
Ta Synchronization Flaky TestsDifficulty 2
How does Cypress's built-in "retry-ability" mechanism handle a command like cy.get('.item').should('be.visible')?
- aIt executes the command exactly once and immediately reports pass or fail based on the current DOM state
- bIt requires the developer to manually wrap the command in a custom retry loop written in JavaScript
- cIt re-queries the DOM and re-checks the assertion repeatedly until it passes or the timeout expires✓
- dIt pauses the whole test run and waits for a human to confirm the element is visible
Explanation:Cypress commands and assertions like .should() are automatically retried against the current DOM state within a configurable timeout (default 4s for most commands) until the assertion passes or time runs out, which is what makes Cypress tests resilient to timing without explicit waits.