Ah, requirements. Gathering requirements is really hard. I’m not a BA, but like most developers, we’ve had to gather requirements at some point. You have to meet with users who might not have enough time for you or might not be able to make up their mind. Then you have to take their ideas and understand the business problem enough so that you can write up requirements. You have to try and find the balance between giving the users what they’re asking for and giving the users what they really need but don’t know it yet. It’s a fine line for sure.
I’m not going to sit here and bash BAs for lousy requirements. I’ve been the one who wrote the requirements only to have a developer mock the requirements (they probably didn’t know that I wrote them or that I was listening, but that’s neither here nor there). I tried really hard and I thought I did a good job. But nevertheless, there were things that I didn’t really think of that the other developers thought of.
Since we know that requirements gathering is hard, what can we do to make sure that we don’t end up with ambiguous requirements, we make it easy to test, and we make sure that we actually give the users what they want?
The key is that we need to find common language that people in different roles can agree on so that we can all be on the same page. Users, BAs, QAs, and developers all think differently and speak different languages. So we need to find a better way to communicate and a better way to write requirements.
The way that we do this is using the Gherkin language, or Given/When/Then format. This goes something like this:
Feature: Transfer money between accounts
As a user
I want to be able to transfer money between active checking accounts
So that I don't overdraw my account
And I don't have to go to the bank to make the transfer
Scenario: Transfer positive amount
Given a checking account "A" that has $100
And a checking account "B" that has $50
When I transfer $10 from account "A" to account "B"
Then the transfer should be successful
Then account "A" should have $90
And account "B" should have $60
At the top of the file we have background information about what the user wants to do and why they want to do it. Then we go step by step and identify all of the scenarios in the Given/When/Then syntax.
So what’s the big deal? Aren’t I just writing the same thing in another format? Yes, but the good thing about the Given/When/Then format is that it helps you find the holes in your requirements and think of all the details and edge cases. If you’re requirements are more in paragraph form with some bullet points, it’s really easy to miss things, even if you’re smart and trying to do a good job.
Essentially what we’re doing here is writing test scripts. As a developer, I want to know how QA is going to test my code. Not only that, I can take these scenarios and automate these tests with acceptance testing tools like SpecFlow or Cucumber or with plain old integration tests or unit tests.
What we did here was establish a common language between everyone involved. This will help BAs think in a detailed, logical way that ensures that they don’t miss things in the requirements. This will help developers because they won’t have to write code to hit a moving target or get stuck waiting for answers to requirements questions. This will help testers because all of their test plans get written up front before the development happens, so they don’t get stuck trying to figure everything out on their own after it’s been developed (and the BAs do a lot of their work because they write their test plans for them). Not only that, this gives the development team the chance to automate the tests. This will help users because once we get the Given/When/Thens done, we can take that to the user and ask them to confirm that we’re building the right thing. We’re still using their terminology, and the syntax will help them think of cases that maybe they hadn’t thought of initially.
If you write your requirements this way, if you get everyone involved up front, and if you write your code to make the tests pass, you should be completely done when you finish development. Because you wrote code against detailed requirements that were written without ambiguity in a manner that makes it easy to write tests for it, you should have no bugs (or at least very very few bugs). QA won’t have to spend lots of time afterwards trying to figure out how to test the feature. And hopefully the users are getting what they want.
Jon,
I’m a BA learning cucumber, and I was am looking for opportunities to improve my skills. I saw that you do the ATDD group, but I am looking for something more specific to using Cucumber and writing scenarios. Would you know of anything like that? Or, would you ever think of hosting something specific to BA’s?
Has no one caught your math error in the example?
Then account “A” should have $90
And account “B” should have $60
@Einstein,
I was just checking to see if anyone was reading. :)
Hi Jon thanks for this nice neat article.
I’m a BA and having some trouble with the length and granularity of Use Cases/Acceptance Criteria.
Do you have a rule of thumb for what level of granularity is appropriate and how long the average Given-When-Then statement should be (i.e. number of lines long)?
Also is it ok to have “AND” after the “WHEN” or “THEN” and have a double loop or should it always be 1x “WHEN” and 1x “THEN” for every flow/scenario?
@MacD,
Generally speaking, I like to have the given/when/then be readable to a business person and express the intent of the business as much as possible. This means trying to keep more technical details out if possible. For example, say “When I add Widget A to the cart” rather then “When I check the checkbox next to Widget A, And I click the Add to Cart button, And I click Next”. At the same time, you have to make sure that you have enough detail that you aren’t being ambiguous. Try some stuff and do whatever works best for you, there’s no hard and fast rules with this.
It’s perfectly normal to have “And”s after “When”s and “Then”s. In fact I usually have lots of Thens.