1. ATDD and User Stories
1.1. What is a user story?
1.1.1. Short Description
1.1.1.1. Not the format is important, but the short description should conform to some rules
1.1.1.1.1. WHO wants WHAT and WHY
1.1.1.1.2. No technical details
1.1.2. Communication
1.1.2.1. Acceptance Criteria may still be added/removed even during the Sprint - the resulting change of scope should not change the estimate (only small changes therefore).
1.1.3. Acceptance Criteria/Acceptance Tests
1.2. Definition of Ready
1.2.1. Level of Detail sufficient.
1.2.1.1. Acceptance Criteria expressed as Scenarios.
1.2.1.1.1. Some details may still be skipped at this point, e.g. some test data may still need to be provided but their nature should already be well-undestood by the Development Team.
2. Practice: creating user stories for an AGILE GURU WEB SITE.
2.1. Team of 4: 3 Developers, 1 Product Owner.
2.2. Write user stories on index cards.
2.3. When you are done, compare with other teams.
2.4. Share.
2.5. 40 mins max.
3. Practice: Introduction to Cucumber
3.1. Calculator
3.1.1. Checkout
3.1.1.1. git clone [email protected]:xp-learner/abe2013.git
3.1.1.2. https://s3-eu-west-1.amazonaws.com/abe2013/git-access-keys.tar.gz
3.1.2. Add multiplication
3.1.2.1. git add .
3.1.2.2. git commit -am 'Multiplication feature added'
3.1.3. Add division
3.1.3.1. Watch out: division by 0
3.1.3.1.1. Separate scenario?
3.2. Browser Testing
3.2.1. Select a page of your choice
3.2.2. Create a scenario
3.2.2.1. Navigate to a page.
3.2.2.2. Fill in some data.
3.2.2.3. Trigger an action.
3.2.2.4. Check results.
3.2.3. Create a scenario
4. Starting up
4.1. Why are you here?
4.1.1. What's in it for me?
4.2. ATDD vs TDD optional
5. Continuous Integration
5.1. It is not just a CI server
5.1.1. It is a practice
5.1.1.1. Rythm
5.1.1.1.1. What is your ATDD cycle?
5.1.1.1.2. What is your TDD cycle?
5.2. Definition of Done
6. To build predictability in our delivery we need to care about both sides of the quality coin:
6.1. External
6.1.1. ATDD
6.2. Internal
6.2.1. TDD
7. What is ATDD?
7.1. ATDD is a collaborative requirements discovery approach in which the requirements are captured as (automated) tests forming executable specifications
7.1.1. It is a communication tool between the business - the Product Owner of the Customer Representative - with the Development Team.
7.1.1.1. WHY? To disambiguate the requirements?
7.1.1.1.1. To clarify the details: REMEMBER A USER STORY IS INTENTIONALLY OPEN FOR CHANGES.
7.1.1.1.2. To define the scope of the delivery.
7.1.2. To add focus and structure to your workflow by driving your internal TDD cycle by a clear testable objectives.
7.1.3. Add transparency to your delivery by shortening your feedback loop: ATDD relies on automation.
7.1.3.1. Get regression free of charge!
7.1.3.1.1. Everybody like to get something for free...
7.2. Slides: Redefining Testing
7.3. Summarising: 3 things about ATDD
7.3.1. Communication with business.
7.3.1.1. CHALLANGE: Product Owner co-located, not only a boss, but a partner from the perspective of the Development Team. PRODUCT OWNER WRITES THE ACCEPTANCE CRITERIA.
7.3.2. Test-first approach.
7.3.2.1. CHALLENGE: Mind-set: test-separation vs test-independence.
7.3.3. Automation.
7.3.3.1. CHALLENGE: Mind-set: automation is expensive.