How do you know that your User Story is truly “Done”?

How do you know that your User Story is truly “Done”? How do you know that existing functionality isn’t broken by the changes?

How do you use specifications to DRIVE development?

Solution: Writing tests as “executable specifications” ATDD & TDD enables us to write executable specifications (through tests) to DRIVE development.

We can view quality at two levels: external quality and internal quality. External quality is from the perspective of the user: does the system conform to their expectations? Internal quality is from the perspective of the developer: is the system maintainable?

Business-facing tests (acceptance tests) help assess external quality. Technology-facing tests (integration tests, unit tests) help assess internal quality. External quality is directly visible to the end-user. Internal quality isn’t directly visible to the end-user (but it can be indirectly seen through the cost of change).

Acceptance tests are executable business specifications from the perspective of the user. Unit tests are executable technical specifications from the perspective of the developer.

How do ATDD & TDD apply to the Definition of Ready (DoR) and Definition of Done (DoD)?

1. DoR should require that Acceptance Criteria should be written for each User Story.
1. DoD specifies that it is necessary that all backlog items must have corresponding passing automated tests, to be marked as Done.

How do ATDD & TDD apply to User Stories?

1. Each User Story should contain Acceptance Criteria. Acceptance Criteria should be testable & human-readable. It could be written in BDD Gherkin-style (written directly in “feature files” or synced from JIRA ticket).
2. At the beginning of the sprint, the QA Automation Engineer automates the Acceptance Criteria (as Acceptance Tests). Can do it alone (silos) or via pair/mob-style (teamwork). They may use BDD framework/tool (Cucumber/SpecFlow) to automate the steps – using for example Selenium to automate the UI. All these tests initially fail.
3. Then within the ATDD cycle, developers initiate the TDD cycle (unit tests and integration tests). Each of these follows the Red-Green-Refactor lifecycle. These should be done “just enough” with the goal of making the overall acceptance test pass.
4. When all the Acceptance Tests pass for a User Story, then that User Story may be marked as Done.

How do ATDD & TDD apply to Bugs?

1. Failing test to be written, which reproduces the bug. Wherever possible, it should be propagated to the lowest level – the unit level.
2. When the failing test passes, then that Bug may be marked as Done.

What are the test proportions? (Test Pyramid)

• Acceptance Tests (e.g. 5%)
• Integration Tests (e.g. 15%)
• Unit Tests (e.g. 80%)

NOTE: The percentages above are for illustrative purposes only, to illustrate proportions.

What are your experiences in using tests as executable specifications?