Selenium WebDriver Risk Assessment & Management 4 — Questions and Answers
Question 1: Which risk is introduced when Selenium tests are written with hard-coded Thread.sleep() calls instead of explicit waits?
- Tests fail to compile on some JVMs
- Tests are unnecessarily slow or still fail if the page loads slower than the sleep duration (Correct answer)
- Browser profiles become corrupted
- WebDriver sessions exceed memory limits
Correct answer: Tests are unnecessarily slow or still fail if the page loads slower than the sleep duration
Hard-coded sleep values either waste time when pages load faster or cause failures when pages load slower than the fixed delay.
Question 2: A risk analysis shows that 30% of test failures are due to StaleElementReferenceException. What mitigation should be implemented?
- Increase heap memory for the JVM
- Re-fetch elements after page interactions that trigger DOM updates (Correct answer)
- Switch to a different browser
- Disable JavaScript in the browser profile
Correct answer: Re-fetch elements after page interactions that trigger DOM updates
StaleElementReferenceException occurs when a cached element reference becomes invalid after DOM changes, so re-fetching elements after such actions resolves this.
Question 3: What risk does running Selenium tests in headless browser mode introduce compared to headed mode?
- Headless mode runs tests slower than headed mode
- Some UI behaviors and rendering differences may not surface in headless mode (Correct answer)
- Headless mode cannot execute JavaScript
- Screenshots cannot be captured in headless mode
Correct answer: Some UI behaviors and rendering differences may not surface in headless mode
Headless browsers may render pages differently or skip GPU-accelerated effects, potentially hiding bugs that only manifest in full-rendering headed mode.
Question 4: In risk management terms, what is the consequence of not maintaining Selenium test data independently from application data?
- Tests cannot be run in parallel
- Test data may be modified or deleted by the application, causing unpredictable failures (Correct answer)
- WebDriver cannot connect to the test environment
- Locators become invalid after each run
Correct answer: Test data may be modified or deleted by the application, causing unpredictable failures
When test data is not isolated, application workflows can mutate or remove it, making test outcomes dependent on execution order and prior state.
Question 5: Which risk does Selenium Grid address in an enterprise testing strategy?
- Risk of test scripts containing bugs
- Risk of insufficient test coverage across browsers and operating systems (Correct answer)
- Risk of slow test authoring velocity
- Risk of incorrect application business logic
Correct answer: Risk of insufficient test coverage across browsers and operating systems
Selenium Grid distributes tests across multiple browser and OS combinations simultaneously, reducing the risk that browser-specific defects go undetected.
Question 6: A Selenium test suite has no retry logic and fails a build whenever a network hiccup causes a transient failure. What risk does adding retry logic introduce?
- Longer test execution times and potential masking of intermittent real defects (Correct answer)
- Tests will always pass regardless of application state
- WebDriver sessions will accumulate and exhaust resources
- Test reports will not record failure history
Correct answer: Longer test execution times and potential masking of intermittent real defects
Retry logic increases run time and can hide genuine intermittent bugs by making them appear resolved, so retries should be limited and logged carefully.
Question 7: Which practice mitigates the risk of Selenium tests producing false positives — tests that pass even when the application is broken?
- Using longer explicit waits
- Asserting on specific element content and state, not just element presence (Correct answer)
- Running tests in incognito mode
- Disabling browser extensions during test runs
Correct answer: Asserting on specific element content and state, not just element presence
Checking only that an element exists can pass even if it displays wrong data; asserting on content and state ensures the test validates actual application behavior.
Selenium WebDriver Risk Assessment & Management 4
Which risk is introduced when Selenium tests are written with hard-coded Thread.sleep() calls instead of explicit waits?