Course Outline
============== Day 01 =====================
Introduction
- Why BDD?
- BDD as an extension of Agile
- Agenda for Day 01
Applying BDD at Different Stages in the Software Development Cycle
- Before development
- During development
- After development
One Language to Rule Them All
- Engineers and non-engineers speak different languages
- Bridging the gap through BDD
- A preview of the BDD language: Gherkin
The Different Roles of BDD
- BDD as product requirements (for product owner)
- BDD as acceptance criteria (for developers)
- BDD as test cases (for testers)
- BDD as a description of the product (for other stake holders)
Back to Agile: It All Starts with User Stories
- Overview of the Agile development cycle
- The role of User Stories in Agile development
Q&A Session and Discussion
Quiz
Creating a Good User Story
- Using the right language
- Role, Action, Outcome
- A sample User Story
Activity - Writing a User Story
- Writing your first User Story - individual activity
- Tightening your User Stories - team activity
- Delivering your User Story - team activity
User Stories in Real Projects
- Team dynamics
- Tools and techniques
- User Stories in the software development cycle
On to BDD
- Extending the User Story
- Introducing the Feature File
- Capturing the expected behavior of software
- Imagining what "unexpected" behavior looks like
Creating a Good Feature File
- Using the right language (Gherkin)
- Given, When, Then
- A sample Feature File
Activity - Writing a Feature File - PART 01
- Writing your first Feature File - individual activity
- Feature section
- Scenario section
- Tightening your Feature File - team activity
- Delivering your Feature File - team activity
Feature Files in Real Projects
- Team dynamics
- Tools and techniques
- User Stories in the software development cycle
Q&A Session and Discussion
Quiz
Setting up Your Environment
- Making Gherkin pretty
- The joy of productivity
Activity - Writing a Feature File - PART 02
- Writing your Feature File - individual activity
- Passing multiple arguments to your Scenario
- Scenario Outline section
- Tightening your Feature File - team activity
- Delivering your Feature File - team activity
Q&A Session and Discussion
Quiz
Closing Remarks
============== Day 02 =====================
Introduction
- Recap of previous day
- Agenda for Day 02
Your Own Product - An Introspection
- Describing your product
- Drawing a picture of your product
Extending Test Coverage
- Usability of the system
- Business requirements
- Business processes
Activity - Writing a Feature File - PART 03
- Writing your Feature File - individual activity
- Examples section
- Reusing data and scenarios
- Organizing features and scenarios with tags
- Tightening your Feature File - team activity
- Delivering your Feature File - team activity
Q&A Session and Discussion
Quiz
The Feature File - What to Leave Out
- What to leave to the engineers
- Low-level functionality (unit tests)
- Exhaustive cross-component functionality (integration and API testing)
Q&A Session and Discussion
Quiz
Your Own Product - An Introspection
- How usable is your product?
- How usable is your product to outside users?
Communication with People outside Your Team
Closing Remarks
Requirements
- An understanding of user requirements concepts
- A discerning eye for software goodness and software inadequacies, from an end-user perspective
- Programming and testing experience are not required
Audience
- Product owners and managers
- Business analysts
- Manual testers
- End-users of a software product or system
- Non-engineers and non-coders involved in product design
Testimonials
Easy and accessible way and training approach.
Monica Merryweather, Leeds Building Society
BDD for Non-Programmers: Live Workshop Course
I liked that we had multiple opportunities to work on creating a feature file. Very good experience. I also like they way we focused on a few scenarios linked to our day to day work load.
Sophie Russell - Monica Merryweather, Leeds Building Society
BDD for Non-Programmers: Live Workshop Course
Craig seemed realistic about the limitations of BDD and what it would NOT be suited for instead of the simple 'evangelising' and its 'good for everything' approach that some proponents of BDD/Agile seem to adopt. Being realistic about the real world gives a lot of credibility in my eyes.