You probably have read that BDD is not about testing, but about improving communication.
In software development, there are a manifold of ways to express the same thing; and some fit better for each role. Given that, it is common for a project to have many documents expressing the same thing. This cause two problems:
- When requirements change, all these documents need to be updated;
- Some documents are "unreadable" for some people - because the notation and language is focused for other people.
BDD - Gherk language, for example - tries to mitigate this problem by creating a simplistic unique source of truth, readable by anyone. Giving unique tags for each scenario, any individual in a team can raise questions about a particular behaviour in the system.
The scenario-based requirements in BDD help:
- Designers and POs express their needs;
- Developers and testers to early check if the system if the behaviour (main flow and alternatives) are as expected.
This does not mean that other documents (as wireframes) can not be used, but they should always be linked in the BDD documents (because it is the single source of truth).
In summary, BDD helps to work with two principles of Agile:
- Embrancing the changes;