image source: https://www.infolytx.com/development/processes/bdd-tdd/attachment/tdd-bdd/

Problem Statement

We all know that BDD/ATDD/TDD is important and learning curve is quite high. In order to get used to it. Here, I write down a manual script to do deliberate practice.

Step by Step

You need to know when to stop writing code or get thing done when you have a user story or many tasks on hand. You have clear definition of done (DoD) in Scrum. Likewise, we need to know if all our artifacts deliver value to our customer. Let's start from clarification of user story.

Spec by Example

• What's the most important business value in this user story? Usually, you will come out few key happy path or most frequently used scenario. We will convert it to E2E test and use it in the regression test.
• Using ubiquitous language to identify or clarify business rule and make implicit knowledge explicit. You can use it in our module, function, variable naming.
• What's most important UX or UI design? UI logic?
  • What part of this app would make me most upset if it were broken?
  • What would be the worst thing to break in this app?
• Do we have better / easier UI design which reduces unnecessary efforts on minor chores?
• Others:
  • Exception handling
  • What is the scope in the user story?

Cheatsheet

• Most important business value? Goal, purpose, happy path?
• Most important UI logic?
• Exception handling
• Better or easier UI design?
• Scope of user story

Acceptance Criteria (AC)

Those are candidates of ACs. You can convert it to the combination of e2e test (happy path), UI test, integration test and unit test 。