BDD Acceptance Criteria Writing !

Acceptance testing doesn't actually mandate the conversations, and usually works from the assumption that the tests you're writing are the right tests. In BDD we assume that we don't know what we're doing (and probably don't know that we don't know). This is why we use things like "Given, When, Then" - so that we can have conversations around the scenarios and / or unit-level examples. (Those are the two levels most people are familiar with - the equivalent of acceptance tests and unit tests - but it goes up the scale).

We don't call them "acceptance tests" because you can't ask a business person "Please help me with my acceptance test". They'll look at you with a really weird, squinty gaze and then dismiss you as that geek girl. 93% of you don't want that.

Acceptance testing doesn't actually mandate the conversations, and usually works from the assumption that the tests you're writing are the right tests. In BDD we assume that we don't know what we're doing (and probably don't know that we don't know). This is why we use things like "Given, When, Then" - so that we can have conversations around the scenarios and / or unit-level examples. (Those are the two levels most people are familiar with - the equivalent of acceptance tests and unit tests - but it goes up the scale).

We don't call them "acceptance tests" because you can't ask a business person "Please help me with my acceptance test". They'll look at you with a really weird, squinty gaze and then dismiss you.

When you write a story, it always has at least one acceptance criteria attached to it (and if the story itself is written as though it were a happy path, that acceptance criteria can be the story itself). But stories usually have more acceptance criteria than just the happy path. Writing acceptance criteria, along with tying them into end to end scenarios makes your story or narrative ready for development. Never go into development without the story or narrative having:

• priority
• story or narrative (depending on complexity)
• acceptance criteria
• knowing what the end to end test scenario is /are
• sign off from the customer for all of the above
• an estimate from iteration based on all of the above

Acceptance Criteria focuses on the vertical testing of that story in every way possible, and should be written in such a way that anyone testing it or developing it understands.

Implementation

When writing Acceptance Criteria, identify the primary purpose and scope. Clearly defined scope keeps the specification content focused. Define what scenarios are in scope and scenarios not in scope. A use case will define a single path through the functionality. There are generally at least a few use cases per story narrative. Effective acceptance criteria is detailed / specific and unambiguous. It should not use subjective language (Fast, Good, Better), or generalisations (Always, Never etc).

SMART Method

Keep SMART in mind when defining acceptance criteria: Specific, Measurable, Achievable, Relevant, Time-boxed.

Methods to writing acceptance criteria

Acceptance Criteria can be fleshed out in 2 ways; Scenario style or Behavior Driven Development (BDD) style.

Scenario style approach to acceptance criteria

This approach is useful when its easy to capture end to end test scenarios (the way the user will actually use the system). It's based on scenarios versus discrete acceptance criteria.
In general, scenario style focus on 'happy' and 'alternate' paths through the functionality and are always written the way the user would complete the action they are trying to take.

ATM example of withdrawing cash:
What is the user story?
As an account holder I would like to withdraw cash from an ATM so that I have money to spend.

Happy Path

For a favourable outcome what business conditions need to be met?
Account Holder enters valid pin
Account Holder has a balance matching or exceeding requested amount
ATM has cash matching or exceeding requested amount
So what should happen when the Account Holder tries to withdraw cash?
ATM dispenses requested cash immediately
Account Holder's balance is reduced
ATM cash balance is reduced
We've just described the happy path for the ATM withdrawal story. The business conditions were identified, and the acceptance criteria we can use to validate that the solution meets the customer's needs was listed.

Alternate path

The path with some deviations that allows users to reach the desired outcome
ATM example continued:
What if any of the business conditions identified in the previous exapmles were not true?
What if the Account Holder enters an amount greater than his balance?
Indicate that there are insufficient funds in his account
Can we stop here? Can we provide some functionality that will allow the user to still reach his goal?
Display a message and Provide option to specify a lesser amount
We can still satisfy the goal even though the path is not direct. This is what some people call an "Alternate Path". This is still acceptable as it allows user to reach his goal.

Bad Path

That path that does not lead to the desired outcome
ATM example continued:
What else can happen? Can something go totally wrong?

For example, maybe you cannot connect to the Bank

Account Holder's card has expired

Unexpected error in the system. Buffer overflow, Null Pointer.

We try our best to prevent these from occurring by writing more test, adding more functionality that caters to these situations (adding resilience). And provide a graceful recovery from unexpected outcomes - error messages and return to start page.

BDD style acceptance criteria

The Behavior Driven Development approach allows us to set the context for each test condition. This approach helps tease out all possible conditions that can affect the story.
Format:
Given 

When

Then

ATM example continued:

The happy path acceptance criteria for cash withdrawal is:

Given that my account has a positive balance, and the ATM has sufficient funds

When I enter a valid pin and ask for the an amount that the ATM can deliver and less than my balance,

Then the ATM will dispense that exact amount and debit my account by the same figure.

The nature of Acceptance Criteria 

• Elaborate stories
• Corroborate stories
• Are described by the business - normally during the development phase
• Are a set of conditions that the story must meet for it to be accepted as complete
• Acceptance criteria do not replace the conversation they are one of the results of the conversation
• Are abstractions of what business value will be observed
• Are generally not tests - tests are concrete e
• Writing Acceptance Criteria
• Should be derived with the customer
• Should be derived with someone technical in the room. Is what we are discussing technically possible?
• Ask the customer what they will observe when the story is successfully complete
• Ask more than one person
• May be many criteria
• All must be met before the story can be accepted

Considerations:

• Environment/Conditions/Context
• Actor involved
• Verb/Actions
• Observable result

Watch out for

• Ambiguous language
• Subjective/Judgemental language (Better, Good, Allowable)
• Generalisations (All the time, Never, Everyone, Always)
• Observed behaviour that is not directly related to the story currently under consideration.