A behavior-driven development (BDD) scenario gets better when other people read it. A group review checks that the scenarios describe what the software should really do, turns up the issues one author reads past, refines the wording, and leaves everyone with one understanding of what users expect. Thirteen steps make a good session: four before it, five during it and four after.
Before the session
1. Select the right participants
Choose people who see the job from different sides: the webmasters on it, the owner, and someone who uses the result every day or knows the trade. Each brings a question the others wouldn’t think to ask.
2. Set clear objectives
Decide what the session is for before it starts: clarity, completeness, accuracy, or alignment with what users expect.
3. Schedule a review session
Put the session on the calendar. The owner has to be there, since the owner settles what a scenario should say. Size the session to the scenarios under review, and keep it short enough that everyone reads each one with care.
4. Distribute scenarios in advance
Send the scenarios out ahead of time, so everyone arrives having read them, with feedback and suggestions ready.
In the session
5. Facilitate the review
One person facilitates: they guide the discussion, keep it on track toward the session’s objectives, and invite open, constructive feedback.
6. Read aloud and discuss each scenario
Read each scenario aloud, the facilitator or everyone in turn, then talk it over: is it clear, is it complete, and is it what users expect?
7. Identify ambiguities and issues
Look for ambiguity, inconsistency and trouble of any kind: unclear language, a missing detail, a line two people read two ways.
8. Propose enhancements
Turn each problem into a proposed fix: more context in a Given, a sharper action in a When, another expected outcome in a Then.
9. Document feedback
Write every piece of feedback and every proposed fix down, so none of it is lost before the scenarios are revised.
After the session
10. Prioritize changes
Rank the changes by how much they improve the scenarios and their fit with what users expect. Some are critical; some are polish.
11. Iterate and revise
After the session, work with the scenarios’ authors to revise them: rewrite, clarify or expand each one the feedback touched.
12. Verify changes
Check that the revised scenarios still describe the intended behavior, and run the automated tests built on them. The lecture Modern Redux Architecture Patterns sets out which test covers which layer, so a revised scenario’s test lands at the right one.
13. Continuous improvement
Keep reviewing for the life of the project: revisit and refine the scenarios as it evolves and as what users expect changes.
A group review catches what one author reads past: a vague step, a missing case, a Then that tests nothing. On the Sean Dinwiddie’s Webmastery team the habit runs to launch: every launch is reviewed against its written scope before it goes live, so no webmaster is the only reader of their own work. The next lesson, on BDD and unit testing, sets out what the scenarios check and what the unit tests beneath them check.