Scenario review
This is the first of a series of posts on how our team is practicing BDD. These are mostly notes to myself and our team so other readers may not find enough context to understand the points.
After a few weeks we have decided that:
- Although source code is written in English, the specifications are written in Spanish. Because the business is always discussed in Spanish, it’s the language used to determine what we need to do. So the Cucumber scenarios are written in Spanish.
- There is a glossary of business terms to help us document the ubiquitous language. The glossary contains the translations from Spanish to English so that the source code expresses the same concepts.
- If developers need to change or adjust the scenarios for some reason (for instance, automation purposes), then business analyst have to validate the changes.
- Scenarios will be stored in only place only, and that place is SpecFlow (Cucumber). This means that business analyst need to have all the tools installed and access to the source control repository (Visual Studio and TortoiseHG).
- After the specifications workshop, scenarios are written in pairs or groups of 3 or 4 people. Two people is usually enough. We’ve realized that writing the scenarios in pairs help us come up with more questions and more ideas to simplify the problem.
- The automation of the scenarios should also be done in pairs, because this is yet another opportunity for us to detect inconsistencies or doubts. Well, in general we just pair most of the time.
- A user story is not ready for implementation until it’s got at least 4 scenarios. We started with just one and the lack of context caused us to introduce wrong models in the code. Actually when test-driving a small function, we never start out with a single example but with a to-do list. Then we focus on each test writing the minimum code required but we do know where we want to go. This is the same but at a higher level.
- Given that our business analyst know how to read code, they should read the source code at the end of the iteration. By reading the part of the code inside the hexagon (we use hexagonal architecture), they can ensure the designed model makes sense.
- Scenarios should not repeat irrelevant details. If one scenario uses real data like a “plate number”, then the following scenarios don’t need to repeat the whole plate number but just something like “x”. We should keep in mind that scenarios complement each other in terms of documentation. They should be indepdendent for execution but not for documentation.
- Triangulation: we can make a scenario go green quickly. However, triangulating the code that really works for all the cases falling under that scenario, may require more code. If the triangulation does not concern business details, we use NUnit to test-drive rather than SpecFlow. Scenarios are used for documentation, not for triangulation, unless the triangulation covers relevant business tips.
It was by chance that one of our business analysts came up to a mob programming session and got to see code related to the scenarios that we had defined together. Quickly he realised that we were introducing aliens in the domain (wrong models). It was because we were lacking some other scenarios. The fact that the code was in the wall with a massive font size and it really communicated our intent, together with the fact that the reader is very clever, made us discover an useful technique to double-check our assumptions.