A number of case studies have shown that a typical developer spends 30% to 40% of their time fixing bugs. Specification by Example/BDD is designed to prevent those bugs and give you back all of that time. If an average developer earns $150,000 annually in salary and benefits, 30% of their time is $50,000 – per developer, per year.
I like to talk about two kinds of bugs – Little-B bugs and Big-B Bugs.
Little-B bugs…
are the ones where the code doesn’t do what the developer intended – the text entry box isn’t large enough, or sorting doesn’t work, or the wrong data is returned by a query.
Big-B bugs…
are the ones where the code does exactly what the developer intended – it just isn’t what the customer wanted. These are immensely costly; your developers may have spent two or three sprints writing really good, clean, highly maintainable code that does the wrong thing!
Specification by Example prevents Big-B Bugs by changing the way that Product Owners, Business Analysts, Developers, and QAs communicate. SBE says that all requirements must include concrete examples; concrete examples make it much easier to discuss the requirements, to understand them, and to find other important examples. This makes it much, much easier to avoid creating Big-B Bugs.
SBE also makes it easy for the QA team to deliver automated tests to the developers before the developers finish coding; this helps prevent both Big-B Bugs and Little-B Bugs.
For example, “As the accounting department, I want late bills to be charged a penalty” is a nice user story, but not acceptable as an SBE requirement. Here is an SBE requirement:
Scenario Outline: Late bills will be charged a penalty on a sliding scale
Given an active customer account
And a bill that is <Days_Past_Due> days past due
When the bill is paid
Then a <Penalty> penalty will be charged
Examples:
| Days_Past_Due | Penalty |
|---|---|
| 14 | 0% |
| 15 | 5% |
| 29 | 5% |
| 30 | 7% |
Writing requirements this way makes it really easy for everyone to communicate clearly; this prevents Big-B Bugs. The QA team can automate this requirement and deliver it to the developers in-sprint; this makes it easy to verify that there are no Little-B bugs.
Implementing SBE/BDD well can save $50,000 per developer per year — how much of that do you want?