Selenium Testing Framework Professional Standards & Competencies 3 — Questions and Answers
Question 1: A Selenium engineer is asked to estimate automation coverage for a new feature. Which approach reflects professional competency?
- Automate 100% of all possible user flows regardless of risk
- Prioritize automation based on risk, frequency of use, and regression value (Correct answer)
- Only automate the happy path and ignore edge cases
- Defer all estimation until after the feature ships to production
Correct answer: Prioritize automation based on risk, frequency of use, and regression value
Risk-based prioritization ensures automation effort delivers the highest return by focusing on high-impact, frequently-exercised, and regression-prone scenarios.
Question 2: Which versioning practice is essential for a professional Selenium test codebase?
- Store test scripts only on the local QA machine for security
- Commit test code to the same version control system as the application code (Correct answer)
- Keep a single master copy and email updated scripts to the team
- Use a separate versioning tool exclusively for test assets
Correct answer: Commit test code to the same version control system as the application code
Storing test code alongside application code in the same VCS (e.g., Git) ensures tests are versioned, reviewable, and aligned with the application they test.
Question 3: A QA lead wants to measure the effectiveness of the Selenium suite. Which metric is MOST meaningful for professional reporting?
- Total number of test scripts in the repository
- Defect escape rate — bugs found in production vs. caught by automation (Correct answer)
- Number of lines of test code written per sprint
- How quickly each developer can manually re-run the suite
Correct answer: Defect escape rate — bugs found in production vs. caught by automation
Defect escape rate directly measures whether automation is catching real bugs before they reach production, which is the ultimate goal of the test suite.
Question 4: When should a Selenium automation engineer advocate for NOT automating a particular test case?
- When the test involves any network calls
- When the feature is highly volatile, one-time, or cheaper to verify manually (Correct answer)
- When the test requires more than two assertions
- Whenever the test case was written by a developer rather than a QA
Correct answer: When the feature is highly volatile, one-time, or cheaper to verify manually
Automating tests for unstable features wastes maintenance effort; highly volatile or exploratory scenarios are often better served by skilled manual or exploratory testing.
Question 5: Which behavior reflects professional code review standards when reviewing a colleague's Selenium pull request?
- Approve immediately to avoid slowing down the team
- Provide specific, actionable feedback on locator fragility, wait strategies, and test data management (Correct answer)
- Focus exclusively on line count and reject anything over 100 lines
- Only comment if the test is failing; ignore style and structure issues
Correct answer: Provide specific, actionable feedback on locator fragility, wait strategies, and test data management
Constructive, specific feedback on locator resilience, synchronization, and data isolation raises the overall quality of the suite and spreads best practices.
Question 6: A Selenium engineer discovers that several tests rely on a live third-party payment service in CI. What is the professional recommendation?
- Run the CI pipeline only during business hours when the service is available
- Replace the third-party dependency with a mock or stub service for CI (Correct answer)
- Disable those tests permanently since payment testing is too risky
- Purchase a dedicated third-party account just for CI testing
Correct answer: Replace the third-party dependency with a mock or stub service for CI
Mocking or stubbing external services in CI removes flakiness caused by external availability and rate limits while preserving test intent.
Question 7: What is the correct professional stance on documenting Selenium test automation decisions?
- Documentation is unnecessary since the tests themselves explain everything
- Key decisions — framework choice, page object patterns, CI integration — should be recorded in an ADR or README (Correct answer)
- Only document tests that are currently failing
- Documentation should be written exclusively by the project manager
Correct answer: Key decisions — framework choice, page object patterns, CI integration — should be recorded in an ADR or README
Architecture Decision Records (ADRs) and README documentation preserve the rationale behind major choices, reducing onboarding friction and preventing repeated debates.
A Selenium engineer is asked to estimate automation coverage for a new feature.
Which approach reflects professional competency?