431_midterm - Behavioral Driven Development(BDD 1 Why Do SW Projects Fail Dont do what customers want Or projects are late Or over budget Or hard to

431_midterm - Behavioral Driven Development(BDD 1 Why...

This preview shows page 1 - 15 out of 563 pages.

Behavioral Driven Development (BDD) 1
Why Do SW Projects Fail?• Don’t do what customers want• Or projects are late• Or over budget • Or hard to maintain and evolve• Or all of the above• How does Agile try to avoid failure? 2
3
Agile Lifecycle Review Work closely, continuously with stakeholders to develop requirements, tests – Users, customers, developers, maintenance programmers, operators, project managers, … Maintain working prototype while deploying new features every iteration – Typically every 1 or 2 weeks – Instead of 5 major phases, each months long Check with stakeholders on what’s next, to validate building right thing (vs. verify) 4
BDD+TDD: The Big Picture Behavior-Driven Design (BDD) – develop user stories ( the features you wish you had ) to describe how app will work – via Cucumber , user stories become acceptance tests and integration tests Test-Driven Development (TDD) – step definitions for a new story, may require new code to be written – TDD says: write unit & functional tests for that code first, before the code itself – that is: write tests for the code you wish you had
Introduction to Behavior-Driven Design and User Stories (Engineering Software as a Service §7.1) 6
Behavior-Driven Design (BDD) BDD asks questions about behavior of app before and during development to reduce miscommunication – Validation vs. Verification Requirements written down as user stories – Lightweight descriptions of how app used BDD concentrates on behavior of app vs. implementation of app – Test Driven Design or TDD (future segments) tests implementation 7
User Stories 1-3 sentences in everyday language – Fits on 3” x 5” index card – Written by/with customer “Connextra” format: – Feature name – As a [kind of stakeholder], So that [I can achieve some goal], I want to [do some task] – 3 phrases must be there, can be in any order Idea: user story can be formulated as acceptance test before code is written 8
Why 3x5 Cards? (from User Interface community) Nonthreatening => all stakeholders participate in brainstorming Easy to rearrange => all stakeholders participate in prioritization Since stories must be short, easy to change during development – Often get new insights during development 9
Creating User Stories How do you know if you have a good user story vs. bad user story? – Right size? – Not too hard? – Is worthwhile? 10
SMART User Stories (Engineering Software as a Service §7.3) 11
SMART Stories • S pecific • M easurable • A chievable (ideally, implement in 1 iteration) • R elevant (“the 5 why’s”) • T imeboxed (know when to give up) 12
Specific & Measurable Each scenario testable – Implies known good input and expected results exist • Anti-example: “UI should be user-friendly” Example: Given/When/Then 1.Given some specific starting condition(s), 2.When I do X, 3.Then one or more specific thing(s) should happen 13
Achievable Complete in 1 iteration If can’t deliver feature in

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture