ATDD and BDD are agile development approaches that emphasize collaboration among stakeholders (such as business analysts, developers, testers, and customers) to define clear and testable acceptance criteria before or as requirements are being finalized. Both techniques promote using concrete examples to drive development and validate understanding.
In ATDD, acceptance test cases are derived directly from user stories or requirements and written before the actual implementation starts. In BDD, scenarios are expressed in natural language (often using Gherkin syntax) to describe behaviors the system should exhibit under specific conditions. In both cases, these tests serve not only as validation tools but also as executable specifications — i.e., shared understanding expressed through concrete examples.
Option B is correct because both methodologies use examples (scenarios/test cases) to describe how a system should behave — serving as acceptance criteria.
Incorrect options:
Option A wrongly suggests BDD defers testing until after requirements are finalized — it actually promotes early collaboration.
Option C is false — in ATDD, test cases are based on predefined acceptance criteria, not written beforehand.
Option D is inaccurate — acceptance tests in ATDD and BDD may be automated but are collaboratively written first, not by test automation engineers alone.
Exact Reference – ISTQB CTFL Acceptance Testing Syllabus (Section 2.2):
“Both ATDD and BDD involve the collaborative definition of test cases before implementation to clarify requirements and serve as product usage examples.”
