Gherkin is one of the most popular languages for writing formal behavior specifications – it captures behaviors as “Given-When-Then” scenarios.
With the help of automation tools, scenarios can easily be turned into automated test cases.
Quick Points
BDD is specification by example.
When someone says “BDD”, immediately think of “Given-When-Then”.
BDD focuses on behavior first.
Behavior scenarios are the cornerstone of BDD.
BDD is a refinement of the Agile process, not an overhaul.
It formalizes acceptance criteria and test coverage.
BDD is a paradigm shift.
Behaviors become the team’s main focus.
12 Awesome Benefits
Inclusion
Clarity
Streamlining
Artifacts
Shift-Left
Automation
Test-Driven
Code Reuse
Parameterization
Variation
Momentum
Adaptability
behavior-driven development
Testing Recommendations
Since BDD focuses on actual feature behavior, behavior specs are best for higher-level, functional, black box tests. For example, BDD is great for testing APIs and web UIs.
Gherkin excels for acceptance testing
However, behavior specs would be overkill for unit tests, and it is also not a good choice for performance tests
Is a use case a requirement or just a story?
Is a scenario just another name for a use case?
Is a use case a formal, semi-formal, or informal structure?
Is there a linking structure for use cases, or do they just come in piles?
make use cases “rigorous
People want a fairly informal medium in which to express their early thoughts
Using these semi-formal structures, we can both
Assert that use cases really are requirements and need a basic structure, and also
Allow people to write whatever they want when they need to.
Here is the semi-formal structure
Linking use cases to actors’ goals
If the software supports those goals, the software will yield the greatest business value.
goals sometimes fail
failure handling
Therefore, a use case is structured into two sections: the sequence of actions when everything goes well, followed by various small sequences describing what happens when the various goals and subgoals fail.
Why do we write things in the use case that are not externally visible behaviors?
contract between stakeholders
there remained a split between those who still wanted to keep use cases short and informal and those who wanted them to be detailed
Here are four key pieces of advice that you should note from the evolution of use cases.
readable use cases might actually get read
Prepare for Multiple Formats
Only Use Them When the Form is Appropriate
Be Aware of Use Case Limits
Use cases should not be used to describe UI designs
use case is normally intended as a requirements document, and the UI design is a design
The same system feature is likely to show up as a line item in multiple use cases
Use cases have a basic mismatch with feature lists
Use cases are not test plans or test cases
Avoid the Standard Mistakes in Use Cases
The two most common and most costly to the project are including too many details and including UI specifics
it’s just that by the time I get subgoals at a good level and remove the design specifics, the task is less than nine step
The greatest value of the use case does not lie in the main scenario, but in alternative behaviors
If the main scenario is between three and nine steps long, the total use case might only be two or three pages long, which is long enough.
The Stakeholders and Interests model fills the holes in the Actors and Goals model
Originally published in STQE magazine, Mar/Apr 2002
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Scrum
works very fine within small teams, adding new functionality in an incremental
way. But how to transform traditional developers into a scrum way of working
and how to align the multiple teams? How to maintain piles of legacy code? And
how to go about solving the specific issues the high tech industry has with
Agile? The session ‘Scrum is not enough!’ will give an overview of these challenges
and presents best practices to address them.
to support the ability for systems to change, we should be able to safely make big changes (supported by automated scenarios), as well as the small ones (supported by automated object specifications).
business goal, one or more actors, one or more impacts and one or more ways to support or prevent these impacts
You always start with the business goal; it is your map’s root node. You then grow the map out from the goal by first identifying all the actors (e.g. the customer or the team) that could help or prevent the project from achieving the goal. Each actor could have multiple ways to help or hinder achieving the goal, we call these impacts.
The last layer of an impact map defines what the project or delivery team can do in order to support or prevent particular impacts from happening, and this is the layer where your software options come into play.
In BDD we use Cynefin to identify which features require the most attention
Value and complexity analysis
reuse
outsource
Cynefin to make strategic planning decisions based on value/complexity analysis
Planning in examples
Usage-centered design
Ubiquitous language
eliminate the cost of translation
borrowed from DDD (Domain Driven Design)
'Given, describes the initial context for the example'When' describes the action that the actor in the system or stakeholder performs'Then' describes the expected outcome of that action
Introducing the three amigos
no single person has the full answer to the problem