Test Analysis and Design

In Acceptance Test-Driven Development (ATDD), acceptance tests are defined collaboratively by three key stakeholders — the customer (or business representative), the developer, and the tester — before development begins, ensuring a shared understanding of the requirements.

Having developers and testers pair up to draft acceptance tests based on technical requirements is wrong because it excludes the customer/business perspective, which is essential in ATDD. Having the product owner and business analysts create acceptance tests and then share them with the team is wrong because it describes a handoff approach rather than true collaboration, violating the collaborative spirit of ATDD. Another option is wrong because it limits participation to testing roles and occurs after story review rather than as a proactive, cross-functional activity.

Key concept tested: the collaborative triad (business, development, testing) in ATDD.

The tester wrote three test cases covering each of the three valid transitions (Red→Green, Green→Yellow, Yellow→Red), which means every valid transition in the state transition diagram has been exercised exactly once, achieving 100% valid transition coverage (also called 0-switch coverage).

Covering all valid and invalid transitions would require additional test cases for transitions that should not occur, such as Red→Yellow or Green→Red. Covering all possible state sequences is not a standard coverage criterion and would imply longer paths through the model. Covering all transition pairs (1-switch coverage) would require testing consecutive pairs of transitions, such as Red→Green→Yellow, which involves sequences of two transitions rather than individual transitions.

The key concept tested is state transition testing and valid transition coverage (0-switch coverage).

According to ISTQB, coverage is a measure of how thoroughly testing has exercised a set of coverage items, so measuring coverage achieved by a test technique directly provides a quantitative way to assess the thoroughness of testing performed.

Measuring coverage does not count the total number of defects found, as coverage and defect count are separate metrics. It does not help determine which technique category to select, since coverage is measured after applying a technique, not before choosing one. It also does not evaluate tester skill levels, as coverage reflects how much of the test basis or code has been exercised, not individual competence.

Key concept tested: coverage as a measure of test thoroughness.