An ATDD Case Study
•Descargar como PPTX, PDF•
1 recomendación•1,954 vistas
Presented at the Columbus ATDD Developers Group in April 2011 with Paul Bahler (@paulbahler) and Kevin Chivington from IGS Energy.
Recomendados
Recomendados
Más contenido relacionado
Destacado
Similar a An ATDD Case Study
Similar a An ATDD Case Study (20)
Último
Último (20)
An ATDD Case Study
- 1. An ATDD Case Study
- 2. So what’s the problem?
- 3. Acceptance Criteria Given I am a logged in user When I go to the final checkout page Then I should see the total cost of the order broken down by product cost, tax, and shipping charges And I should see the total cost of the order
- 4. The 3 Amigos
- 6. The 3 Amigos “…it’s like delivering a baby.”
- 7. Feature: Process an order Given I am a logged in user When I go to the final checkout page Then I should see the total cost of the order broken down by product cost, tax, and shipping charges And I should see the total cost of the order • Order total = total cost of products on the order + tax + shipping charges • Tax: – Ohio = 7% – Michigan = 6.5% – Other states = 0% • Shipping: – If total cost of products (before tax >= $25), shipping is free, otherwise $5
- 9. The Board
- 10. “Before ” What happens when testing isn’t included in your definition of done
- 11. “After ” What happens when testing IS included in your definition of done
- 12. Who Writes the Tests
- 13. Co-location
- 14. “The Pod”
- 15. Open workspace
- 17. Reasonably Thorough Requirements "Walking on water and developing software from a specification are easy if both are frozen." ~ Edward V. Berard
- 18. Project Management • Self-directed teams • Everyone is responsible • PMs lay out the roadmap • Shared risk with the business • Risk based testing
- 20. Why work incrementally towards continuous improvement?
- 21. We’re not there yet… • Continuous improvement across teams • Better involvement with business sponsors • More visibility of continuous integration build • 75% of test cases automated in 2012
- 23. Thanks! • Paul Bahler – pbahler@igsenergy.com – @PaulBahler • Kevin Chivington – kchivington@igsenergy.com • Jon Kruger – jon@jonkruger.com – @JonKruger
Notas del editor
- Need to break down features enough so that you can discuss them at a granular levelRegardless of estimation method, this is a good time to right-size stories (estimating, re-estimating, or breaking down the story further)
- Need to break down features enough so that you can discuss them at a granular levelRegardless of estimation method, this is a good time to right-size stories (estimating, re-estimating, or breaking down the story further)
- An “on-going conversation” throughout the life of the user story / card.If BA finds something, developer and tester are informed.If Dev finds something, BA and QA are informed.If QA finds something, BA and Dev are informed.“Close the loop” and keep all domains aware of any changes / gaps / problems / decisions.
- “Insanity: doing the same thing over and over again and expecting different results.” ~Albert Einstein