Sample questions
Qa Test StrategyDifficulty 1
In the test pyramid model, what does the shape (wide base, narrow top) represent?
- aThe order tests must be written in during a sprint
- bThe number of testers assigned to each release layer
- cHow many tests exist at each level, most near the bottom✓
- dThe seniority required to write tests at each layer
Explanation:The test pyramid is a guideline for the relative proportion of tests at each level: many fast, cheap unit tests at the base, fewer integration tests in the middle, and a small number of slow, expensive end-to-end tests at the top. It is not about writing order, staffing, or seniority.
Qa Test StrategyDifficulty 2
Why do unit tests typically form the largest layer of the test pyramid?
- aIsolation from dependencies keeps them fast and cheap✓
- bThey are the only tests that detect logic errors
- cThey are required by regulation in most organizations
- dThey remove any need for manual testing
Explanation:Unit tests isolate a small unit of code from its dependencies, which makes them fast and cheap to maintain, so teams can afford many of them. Integration and end-to-end tests also catch logic errors but more slowly and expensively; unit tests are not a regulatory requirement, and no test level eliminates manual testing's value.
Qa Test StrategyDifficulty 2
A team's test suite has 800 unit tests, 150 integration tests, and 20 end-to-end tests. Does this distribution follow the pyramid's recommended shape?
- aNo, the total count is too low for production
- bYes, the count shrinks going up each level✓
- cNo, integration tests should outnumber unit tests
- dYes, but only because end-to-end tests are most valuable
Explanation:The pyramid shape is about proportion: counts shrink sharply from unit (800) to integration (150) to end-to-end (20), matching the recommended shape. There is no fixed total-count threshold, integration tests are not meant to outnumber unit tests, and end-to-end tests being few reflects their cost, not their relative value.
Qa Test StrategyDifficulty 1
What is risk-based test planning?
- aWriting tests only after a bug reaches production
- bAssigning test tasks to the least experienced engineer
- cRunning every possible test case to eliminate all risk
- dFocusing effort on the riskiest areas first✓
Explanation:Risk-based test planning directs limited testing resources toward areas where failure is more likely or more damaging, rather than treating every part equally. It is not about reacting only after production bugs, staffing by inexperience, or exhaustive testing everywhere.
Qa Test StrategyDifficulty 2
A product has a rarely-used settings page and a checkout flow handling payments for every customer, with similar code size. Using risk-based planning, where should more test effort go?
- aCheckout, because failure there has high impact and reach✓
- bSettings, because less-used features hide more bugs
- cBoth equally, since code size is what matters
- dNeither specifically; split effort evenly regardless of usage
Explanation:Risk-based planning weighs both probability and impact. Checkout has high impact (financial, affects every customer), making it the higher-risk area even if its bug probability is similar to other features. Code size alone does not determine risk, and splitting effort evenly ignores actual consequences.
Qa Test StrategyDifficulty 1
What does code coverage measure?
- aThe percentage of requirements implemented
- bHow much code the test suite executes✓
- cThe number of bugs found per test case
- dThe percentage of tests passing on first run
Explanation:Code coverage measures how much source code is executed while running the test suite. It says nothing directly about requirements met, bugs found, or pass rate — a test can execute a line without verifying its correctness.