Behavior Driven Development (BDD) scenarios effectively express examples of how a system should behave but after writing hundreds of them I find that they don't comprehensively express business rules.
For example, in Dan North's introduction to BDD, it shows how to express scenarios for a bank's handling of a customer's request for cash. Although it shows examples of what should happen if the customer's account is above or below an overdraft limit, the scenarios do not actually define the business rule.
Scenario 1: Account is in credit
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
Scenario 2: Account is overdrawn past the overdraft limit
Given the account is overdrawn
And the card is valid
When the customer requests cash
Then ensure a rejection message is displayed
And ensure cash is not dispensed
And ensure the card is returned
What is the overdraft limit??? Writing BDD scenarios this way does not effectively express the business rules. How can BDD scenarios be used to express business logic?
I've been trying to express business logic in BDD scenarios by using BDD's "scenario outlines" as defined by Gherkin. In the scenario title I focus on the user action and then specify what the response should depend on. I succinctly state the business rule, for example that the overdraft limit is $1000. Here's how it looks:
Scenario: Request cash should not overdraw past the overdraft limit of $1000
Given the account is in <account_state>
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure <customer_response>
And ensure cash is <cash_response>
And ensure the card is returned
Examples:
| account_state | customer_response | cash_response |
| in credit | the account is debited | dispensed |
| overdrawn | a rejection message is displayed | not dispensed |
In Specification Pattern vs Spec in BDD it talks about expressing business logic but expresses some confusion about it. Maybe it's saying the business logic should be expressed using Domain Driven Design (DDD) and that examples should be expressed as BDD scenarios for acceptance criteria. But I don't know DDD and would prefer to see how BDD scenarios can simply be written differently to express business logic.
Is there a better way to express the full business as BDD scenarios? We don't want mere examples; we want the rule. By analogy, in math you can express points on a curve or you express the equation that fits all those points. We want the equation, not the points.
You can write the rules in free text at the top of the feature file and then illustrate them with examples in scenarios
The step Given the account is overdrawn has the overdraft limit hard coded in the step definition, mostly likely. In this particular scenario the overdraft limit is not the behavior being tested. The behavior being tested is attempting to withdraw cash from an overdrawn account. The overdraft limit is not an important detail to the scenario, therefore the overdraft amount is not specified.
The specific amount for the overdraft limit would be its own scenario — most likely multiple scenarios.
Related
I'm new to Gherkin / ATDD / BDD. I'm drafting the following acceptance test:
Given a user is waiting for an operation to complete
And the operation is <percent>% complete
When <threshold> seconds elapse
Then a progress indicator should be displayed
And the progress indicator should display "<percent>%"
Is this specific enough or should I modify the Given clause to represent a more concrete example (thinking in SBE terms), for instance by citing a specific persona instead of just "user" or citing the exact "operation" that is in progress (e.g.: fetching customer list)?
Thanks,
Tony
Progress bars are asethetics.
The only real way to test an aesthetic is to show it to people and see what they think. A/B testing is really good for this. BDD isn't particularly well-suited to aesthetics, because aesthetics are not really about the desired behaviour of the system, but about the desired behaviour of the users.
We're still learning how to program people effectively. Until then, test aesthetics with humans, not scripts.
If there's some algorithm that lends itself to an aspect of behaviour of the progress bar then sure, that would be worth testing... but as others have said, that's something best left for class-level BDD, where the examples are tied more directly to the code.
At that level, you can just put the "Given, When, Then" statements in comments and it's good enough. Class-level steps aren't reused in the same way as system-level steps are, so making them into reusable abstractions isn't as important as making them easy to change. Stick with J/N/WhateverUnit and mock the rest out.
BDD
Behaviour Driven Development is all about conversations between the development team and the business. The feature files and scenarios within them should always relate to a specific business need, a feature or an ability that means that both the business and the development team are fully clear between them on exactly what is outlined.
As an example:
Feature: Rewards for frequent flyers
As a frequent flyer
I should receive points to my account
So that I am more likely to book with BDD Airlines again in the future
Scenario: I get flyer miles
Given I book a flight
And this flight earns 100 miles
When I land
Then my account should have 100 miles added to it
The question is, does this outline the entire problem or is there more information needed?
Would the development team be able to build something using this conversation (As you are on about SBE)?
Would this be better?:
Feature: Rewards for frequent flyers
As a frequent flyer
I should receive points to my account
So that I am more likely to book with BDD Airlines again in the future
Scenario: Passenger gets flyer miles
Given the account number 12341234 has a ticket for the "LGW-MAN" flight
And this route earns 100 miles
And the ticket is scanned at "LGW"
When the flight lands at "MAN"
Then the account 12341234 is rewarded 100 miles
Scenario: Passenger missed their flight
Given the account number 12341234 has a ticket for the "LGW-MAN" flight
And this route earns 100 miles
And the ticket is not scanned at "LGW"
When the flight lands at "MAN"
Then the account 12341234 is not rewarded any miles
Scenario: Passenger gets kicked off the plane
Given the account number 12341234 has a ticket for the "LGW-MAN" flight
And this route earns 100 miles
And the ticket is scanned at "LGW"
But the ticket is removed from the flight
When the flight lands at "MAN"
Then the account 12341234 is not rewarded any miles
It's all about clarity, and is usually more about how the behaviours of the system are described in relation to the business.
Your Example
I personally wouldn't write a Scenario for the purpose of testing a progress bar, as the business shouldn't be interested in the implementation of any components used (they don't care about the loading bar, they just care that the information actually loads).
This would be better as a unit test in my opinion.
Yes, you should be more specific. If you have only one type of user or if this test case applies to every user group "user" is probably good enough for your test. However, I think you should specify the operation that has to be waited on, because TDD is all about feeling safe about your code and how can you be sure it is working everywhere if you haven't tested it for all the operations that could cause a delay?
i've been trying to figure out how to deal with Business Rules in the following format:
a booking has 1 to n (n = 200) articles
problem P shall be handled by the System XYZ
a specifict data-class shall be supported in the System XYZ
the communication to the customer shall be done by the organization Z.
it is possible to change a specific value in an order
the system XYZ shall be able to evaluate if a customer is able to pay monthly rates
in addition, many rules i got explain certain things that need to be fulfilled in order to let a future system work correctly. In my eyes, these rules are technical requirements. So, what would be the best choice? Hard-coding these Business Rules in Business Processes (it just sounds so wrong) or embedding a Business Rule Management System (with a Rules Engine) next to a Business Process Management?
My guess is that a Rule Engine is not the best choice for this. There are sometimes more than one possibilities and scenarios written down in each Business Rule and the common "if-then" statement does not apply in the most cases.
So i found out that in most cases there is this "if-then" statement (literature etc.), but then the SBVR from the OMG comes in (Semantics of Business Vocabulary and Business Rules). It confuses me because there it isn't required to formulate rules with "if-then" et cetera.
I assume that these rules are not specifically meant to be built in a rules engine, but rather kept an eye on during the implementation of the software and after this process. Yet i think that these Business Rules might change. Wouldn't it be naive to hard-code them in Business Processes?
If there's anyone with a hint, i'd be very thankful.
BR
Yeah, you just need to choose the right tool for the job. You should take a look at the Drools and JBPM projects. Where the main goal is to make the rule engine to coexist with the process engine. So for some of those "Rules" you can create a business process to take care of it and for another one you can just write a proper business rule. And the third option is to mix both worlds.
The Specification By Example book states the non-functional requirements (commonly referred to as NFRs) can be specified using examples.
I've also been told by a colleague that non-functional requirements may be specified using SBE stories using the format:
Scenario: ...
Given ...
When ...
Then ...
Here is an example functional and non-functional requirement taken from wikipedia:
A system may be required to present the user with a display of the
number of records in a database. This is a functional requirement. How
up-to-date this number needs to be is a non-functional requirement. If
the number needs to be updated in real time, the system architects
must ensure that the system is capable of updating the displayed
record count within an acceptably short interval of the number of
records changing.
Question 1: Can the non-functional requirement be specified as a story?
Question 2: Should the non-functional requirement be specified as a story?
Question 3: What would the story look like?
I'll give an answer by working through an example.
Let us say that your team has already implemented the following story:
Scenario: User can log in to the website
Given I have entered my login credentials
When I submit these credentials
Then I get navigated to my home screen
To answer Question 1) - Can the non-functional requirement be specified as a story?
The project stakeholders have given you a NFR which reads:
For all website actions, a user should wait no longer that five
seconds for a response.
You could create a story for this as follows:
Scenario: User can log in to the website in a timely fashion
Given I have entered my login credentials
When I submit these credentials
Then I get navigated to my home screen
And I should have to wait no longer than the maximum acceptable wait time
Note that instead of imperatively specifying '5' seconds, I have kept the scenario declarative and instead specified "wait no longer than the maximum acceptable wait time".
To answer question 2) - Should the non-functional requirement be specified as a story?
The NFRs should definitely be specified as a story.
Creating a story will allow this task's complexity to be estimated (so that the team can determine how difficult it is relative to past stories), plus the team can break the story down into tasks (which can be estimated in hours, so that you can work out if the team can implement this story in the current sprint).
Hence in my contrived example, the team would have already implemented the code to log-in, but they'd then determine how to implement the requirement that it must take no longer than 5 seconds to log in. You will also allow be able to explore the inverse of this problem i.e. what happens if it takes longer than five seconds to log-in? e.g.
Scenario: User encounters a delay when logging in to the website
Given I have entered my login credentials
When I submit these credentials
And I wait for over the the maximum acceptable wait time
Then the Production team is informed
And the problem is logged
And I get navigated to my home screen
And finally, regarding question 3) - What would the story look like?
I've detailed how the stories would look like in answers 1) and 2)
Q1: Yes, definitely they can.
Take a look on that article describing Handling Non Functional Requirements in User Stories.
Q2. From my perspective if you able to create them it's really worth of keeping and tracking them in such a way. But citing this article
There is no magical agile practice that helps you uncover NFR. The
first step is to take responsibility. NFR can be represented as User
Stories if the team finds a that this helps to keep these visible.
However, be aware that surfacing such stories may create issues around
the priority of work done on them against more obvious features.
Q3. Take a look on the mentioned article from Q1.
I think the boundaries of NFRs are still not fully agreed upon by everyone. Consider a story that says "As a manager, my employee must get all responses within 5 seconds to avoid hiring a second data entry person and adding $50,000 in payroll expenses." I consider that a fully functional business requirement, along with any performance requirements that focus on the end user experience.
I categorize "traditional" NFRs as stories where the impacted person is not in the end user's or stakeholder's organization. "As a support person I need logs of the web site traffic to help me troubleshoot problems," or "As a software maintainer, I need a block architecture diagram to help me make changes." Including the role as you would with any user story helps with prioritization. It also helps identify the stakeholder for that NFR, should you have any questions about it.
NFRs may include some aspects of performance, at least those that don't impact the end user. "As a system administrator, I want to allocate no more than 10GB of disk space to the database in order to use SQL Express and avoid expensive SQL Server licenses."
Consider a typical NFR that might only state "Databases are limited to 10GB." It's an arbitrary number with no meaning or rationale, and there's no way to question it. Having the story-like role and explanation helps everyone understand that there is a valid reason for the NFR, so when you're prioritizing them you can ask smart questions. They lead to conversations like "I need to expand my table space to 20GB, but the sysadmin has this NFR about database size. How much do SQL Server licenses really cost him? OMG, that much? OK, I'll denormalize a few tables and save a few GB to fit it in there."
As both #bensmith and #siemic show, yes, you can can capture NFRs as stories.
Should you capture them in this way?
I don't think you want to capture NFRs as part of regular feature stories.
Most NFRs apply to more than one story. "The system must be responsive" means every story needs to define maximum wait times. "The system must not consume more than 10GB of disk space" means every story needs to consider disk space. The list of "and"s in the story becomes unmanageable in even trivial cases.
You may want to capture NFRs as independent stories, if both the product owner and team are comfortable with this.
For instance:
Given I have a PC with at least a dual core processor
and 8GB of RAM
and a gigabit connection to the system
when I interact with the system
then I never have to wait more than 5 seconds for a response
and 90% of attempts respond within 1 second
This provides a clear requirement, with measurable targets. You just have to make sure that each story takes all of the NFRs into account.
I think you need to look at a few things,
NFRs should follow the life span of the application, software, product etc. backup and recovery scenarios should be covered regularly, security scans and performance should be measured in prod as well as in development.
Many NFRs need validation from teams outside of the development group so would not be expected to have a script or code written to verify. So obviously security, performance, scalability, resilience etc can and should be tested within the development phase or before code gets promoted into live.
Most NFRs can be written up as stories but as said I dont think all need development effort to cover them.
regards
Martin
Hi all I'm doing the edx course and in this answer I get an error
So if any of you knows the correct answer please tell me why I get an error, if I select all options as true.
Which of the following are true about user stories? Select all that apply.
They should describe how the application is expected to be used
They should have business value
They do not need to be testable
They should be implemented across multiple iterations of the Agile lifecycle
From the SaaS textbook:
The BDD version of requirements is user stories, which describe how the application is expected to be used. They are lightweight versions of requirements that are better suited to Agile. User stories help stakeholders plan and prioritize development. Thus, like BDUF, you start with requirements, but in BDD user stories take the place of design documents in BDUF.
...
User stories came from the Human Computer Interface (HCI) community. They developed them
using 3-inch by 5-inch (76 mm by 127 mm) index cards, known as “3-by-5 cards.” (We’ll see other examples of paper and pencil technology from the HCI community shortly.) These cards contain one to three sentences written in everyday nontechnical language written jointly by the customers and developers. The rationale is that paper cards are nonthreatening and easy to rearrange, thereby enhancing brainstorming and prioritizing. The general guidelines for the user stories themselves is that they must be testable, be small enough to implement in one iteration, and have business value.
Therefore, the answer to:
Which of the following are true about user stories? Select all that apply.
They should describe how the application is expected to be used
They should have business value
They do not need to be testable
They should be implemented across multiple iterations of the Agile lifecycle
is (1) and (2).
Take two different ways of stating the same behavior.
Option A:
Given a customer has 50 items in their shopping cart
When they check out
Then they will receive a 10% discount on their order
Option B:
Given a customer has a high volume of items in their shopping cart
When they check out
Then they will receive a high volume discount on their order
The former is far more specific. If someone has some question about exactly when a customer gets a high volume discount or how much to give them, reading this scenario makes it very clear. Serving the purposes of documenting the behavior, it's about as specific as it can be, although any change in those values will require changing the scenario.
The second is more generalized and doesn't have the clarity of the first. Automating it would require incorporating the values "50" and "10" in the step implementations. On the other hand, the scenario captures the core business need: a high volume customer gets a discount. If we later decide to use "40" and "15", the scenario doesn't have to change because the core business need hasn't really changed (though the step implementation would). Also, the term "high volume customer" communicates something about why we're giving them the discount.
So, which is better? Rather, under what circumstances should I favor the former or the latter?
I think I'll go for option A.
The thing is that BDD scenarios must serve as documentation of the system.
So if a non technical wants to know how your discount system is working (A business guy, a tester or someone from the customer support team), they surely would like to know what it means to have a high volume of item and what it is the applied discount.
And they would not want to have to go in the plumbing code to get this information back.
I think this information is important and can not be hidden from the reader.
Another benefit is that it will allow for a non developer (a tester for example) to write new scenarios and check what will happen if there are 1 item in the cart or 100 items.
When you get too much abstract about thing, it gets harder to apply deliberate discovery.
So with a scenario as in Option B, you loose the opportunity to ask your self these questions:
What happen if we have more than 50 items like 100 items is there any other discount available
What happen if we have 1 item, surrely we need to not apply a discount or should we apply a discount based on the total price of the cart instead of the number of items in it, someone buying only one really expensive item should benefit a discount too ?
is 10% the only available type of discount, do we have for example fixed amount discounts ? Do we have more complex discount strategies ?
When the business variable are visible, you can play around with them and figure out stuff that you may have forgotten or think about new interesting (or not) features.
As a general rule, I'd hide what it does not matter to know in a scenario and in that case the number of items and the applied discount value do really matter to the reader.