Software Testing - Specification by Example (SBE) / Acceptance Test-Driven Development (ATDD)

Image

Specification by Example (SBE) and Acceptance Test-Driven Development (ATDD) are Agile practices where requirements are defined collaboratively using concrete examples, and those examples are turned into acceptance tests before development starts.

Simple definition:

Discuss → Write examples → Turn into tests → Build software to pass them

Core Idea (Straight to the Point)

  • Requirements are not written as vague text

  • They are written as executable examples

  • These examples become acceptance tests

  • Development is driven by these tests

This ensures shared understanding and no requirement ambiguity.

Who Is Involved (Collaboration)

ATDD is a three-way collaboration:

  • Business / Product Owner – defines expected behavior

  • Tester / QA – converts examples into acceptance tests

  • Developer – implements code to satisfy tests

This is why ATDD is also called “Three Amigos” practice.

ATDD Workflow

  1. Requirement discussion

  2. Concrete examples are defined

  3. Acceptance tests are written (before coding)

  4. Development starts

  5. Tests must pass

  6. Feature is accepted

Testing drives development, not the other way around.

Example (Given–When–Then)

Requirement: Login should fail for invalid password

Given the user is registered
When the user enters an invalid password
Then login should be denied with an error message

This example is:

  • A requirement

  • A test case

  • A validation rule

All in one.

Specification by Example vs Traditional Requirements

Aspect Traditional Requirements SBE / ATDD
Format Text documents Concrete examples
Ambiguity High Very low
Validation After development Before development
Tester involvement Late Early
Automation support Weak Strong

Relationship Between SBE and ATDD

  • Specification by Example → How requirements are described

  • ATDD → How development is driven using those specifications

They are usually used together in Agile teams.

Benefits (Why Agile Teams Use It)

  • Eliminates requirement misunderstandings

  • Reduces rework

  • Improves communication

  • Enables automated acceptance testing

  • Acts as living documentation

  • Faster acceptance by stakeholders

Where It Is Used

  • Agile / Scrum teams

  • Behavior-Driven Development (BDD)

  • Continuous Integration pipelines

  • Product-centric development

Common Tools (Just for Context)

  • Cucumber

  • SpecFlow

  • FitNesse

  • JBehave

(These tools execute the examples as tests.)

Limitations 

  • Requires active business involvement

  • Initial setup effort is higher

  • Poor examples → poor tests

  • Not ideal for highly exploratory features