Sample questions
Qa Automation FundamentalsDifficulty 1
In the classic test automation pyramid, which layer is meant to hold the largest number of tests?
- aUnit tests — fast, cheap, and pinpoint failures precisely✓
- bEnd-to-end UI tests, because they best replicate real user behavior
- cManual exploratory tests, because judgment cannot be automated
- dIntegration tests, because they cover the most business logic per test
Explanation:The pyramid shape reflects cost and speed: unit tests run in milliseconds and pinpoint failures precisely, so they form the wide base. b and d put the bulk of coverage in slower, more expensive layers, which the pyramid explicitly avoids. c misreads the pyramid as an argument against automation rather than about layer proportions.
Qa Automation FundamentalsDifficulty 2
A test scenario will be executed exactly once, to verify a one-time data migration, and never again afterward. From an automation ROI perspective, what is the most reasonable approach?
- aAutomate it fully, since automation is always superior to manual testing
- bTest it manually, since one execution won't repay a script's cost✓
- cAutomate only the final assertion and do the rest by hand
- dSkip verification, since one-time migrations rarely need checking
Explanation:Automation ROI comes from repeated execution amortizing the upfront cost; a scenario run exactly once never recovers that cost, so manual verification is the rational choice. a treats automation as universally better, ignoring cost. c and d either half-solve the problem or skip verification of a risky operation entirely.
Qa Automation FundamentalsDifficulty 2
Which scenario gives an automated test suite the strongest return on investment?
- aA UI layout check on a screen that changes almost every sprint
- bA one-off manual data check for a single ad-hoc report
- cA stable core flow, like checkout, re-verified each release✓
- dA brand-new experimental feature still under active design changes
Explanation:ROI rises with stability and repetition: a stable flow tested on every release amortizes automation cost across many runs with low rework. a and d are still changing, so the automated checks need constant rewriting; b is executed once, so there is nothing to amortize the cost against.
Qa Automation FundamentalsDifficulty 1
What is a "flaky" test?
- aA test that always fails because of a real bug in the code
- bA test that is too slow to be included in the CI pipeline
- cA test that has been deprecated but not yet removed
- dA test that passes or fails with no code change✓
Explanation:Flaky describes non-deterministic outcomes on an unchanged system, which erodes trust in the suite. a describes a consistently failing (deterministic) test, which is a real bug, not flakiness. b and c describe unrelated maintenance issues, not inconsistent results.
Qa Automation FundamentalsDifficulty 2
An automated test clicks a button that triggers an asynchronous update, then immediately checks the result and occasionally fails even though the feature works correctly. What is the most likely root cause?
- aThe test checks the result before the update finishes✓
- bThe test environment's database has become corrupted
- cThe button element has an accessibility labeling problem
- dThe test is running against an outdated build of the application
Explanation:Checking immediately after triggering an async operation races against variable completion time, which is a classic timing-based flakiness pattern. b, c, and d would cause consistent, reproducible failures, not the intermittent "sometimes passes" pattern described.
Qa Automation FundamentalsDifficulty 2
Two tests pass reliably when run alone, but the second one fails intermittently when run right after the first, because the first test leaves behind a record that changes the count the second test checks. What best describes this cause?
- aA timing or race condition between asynchronous calls
- bLeftover state from the first test changes the second test's start✓
- cAn unstable network connection between the runner and the server
- dThe CI tool randomized the execution order of the tests
Explanation:Leftover data from one test changing another test's starting conditions is the definition of state leakage between tests. a is unrelated, since nothing here is asynchronous timing; c is not indicated; d describes ordering being randomized, not the actual mechanism of failure, which is shared mutable state.