BDD
Technique that encourages collaboration between developers, QA and non-technical or business participants in a software project. It was originally named in 2003 by Dan North[1] as a response to Test Driven Development, including Acceptance Test or Customer Test Driven Development practices.
BDD focuses on obtaining a clear understanding of desired software behaviour through discussion with stakeholders. It extends TDD by writing test cases in a natural language that non-programmers can read. This allows the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the business, users, stakeholders, project management, etc.
Some Jargon
Stakeholder
A Stakeholder is a person who gets some value out of the system. Typical stakeholders are representative of groups of users, for example a trader or an administrator.
Feature
A Feature is a piece of system functionality that delivers value to one or more stakeholders. Executable specifications work best when described from the perspective of stakeholders, not technical infrastructure, since doing so enables business users to understand them better and engage more in discussions about what makes a particular feature complete.
Features are normally vertical functional slices of the system, for example transaction processing. Horizontal infrastructural slices, for example authorization, are not good as features. They do not deliver value directly to any stakeholders. Stakeholders will not be able to engage properly in specifying the acceptance criteria for such functionality, pretty much defeating the point of specification by example.
User Story
A User story is a rough description of scope for future work, used as a planning tool. Stories are vertical slices of system functionality that are deliverable independently. Each story should specify the value it brings to one or more stakeholders, the stakeholders that care about the story and the scope of the intended work. A common format for the stories is:
As a ..., I want..., So that... or In order to..., as a ..., I want ...
Stories often impact several features — a payment story might have an impact on transaction processing, fraud control and back-office reporting. Stories are often relatively small chunks of work to support frequent delivery. A single feature might be delivered through a large number of stories.
Good stories are not broad in scope and should be able to kick off a meaningful discussion.
What is SpecFlow (specflow.org)
A Tool to bind business readable behavior specifications to the underlying implementation. ie creates "Acceptance" test stubs for your features/User Stories, to help know when done is done at least for development.
Feature File
A Feature file describes a feature or a part of a feature with representative examples of expected outcomes. Specflow uses these files to validate some system functionality against its specifications. Feature files are plain-text files, ideally stored in the same version control system as the related project.
Each feature should be illustrated with Key Examples (Scenarios). The examples show the expected outcomes in specific representative cases with very precise information. This makes it absolutely clear what the system is expected to do and helps to avoid any misunderstanding and ambiguity. It also makes it possible for Specflow, to check whether the system works according to the specification.
Scenario
A Scenario captures one key example for a feature in the feature file. It represents a way that the system delivers some value to a stakeholder. Scenarios are units of specifications for Specflow. Scenarios allow us to chop up feature functionality like Sushi, into chunks that can be separately consumed. Examples of good scenarios for credit card processing might be successful transaction authorization, transaction failure due to lack of funds, transaction failure due to wrong verification code and so on.
Steps
Steps are domain language phrases that we can combine to write scenarios. They can either refer to the context of a scenario, an action that the scenario describes or a way to validate the action.
What Makes a Good Feature File
The long term benefit of using Specflow comes from living documentation, a source of information on system functionality that is easily accessible to everyone and always current. To achieve that, a feature file should be:
- Easy to understand
- Consistent
- Easy to access
To serve as a target for development that prevents misunderstanding and ambiguities, scenarios in a feature file should be:
- Precise and testable
- Specifications, not scripts
- About business functionality not about software design.
Once a feature is implemented, the related file becomes a living document for the feature. To allow the software to evolve and provide functional regression checks, the scenarios should be:
- Self explanatory
- Focused
- In domain language
Most importantly these files should be written collaboratively... BAs, Stakeholders, QAs, and Devs
So once the feature file is written Specflow will create some stubbed tests of the scenarios. the development team's responsibility is to fill in the stubs, and then make these tests pass. This does not mean that the developer wont need to write unit tests, since the tests created by Specflow are more broad in scope.
So once all the Specflow tests pass the developers know they have met the needs of the Stakeholder and can confidently check in their code.
No comments:
Post a Comment