Acceptance Test Driven Development (ATDD) is a movement within agile to improve the quality of and success of our projects by changing how we capture our requirements and by changing how and when we test. Borrowing from the Lean toolbox, we’ll use Value Stream Mapping (VSM) to compare traditional test & fix cycles to ATDD used in an agile context. Participants will be given an introduction to ATDD and VSM and will participate in creating and analyzing two Value Stream Maps. Target audience includes all members of the team including Testers, PMs, Developers and Analysts. Caution: Participants are warned that using VSM to map out your partner’s wasted efforts in completing household chores will not cause the harmony you imagined it would. For more of the tragic details, attend the session.
Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...
Using Value Stream Mapping to make the case for Acceptance Test Driven Development
1. Using Value Stream Mapping to make the case for Acceptance Test Driven Development Brought to you by: Aaron “I value streamed my marriage proposal” Nelson and Steve “I value streamed our laundry process” Rogalsky @srogalsky winnipegagilist.blogspot.com
5. What is Acceptance Test Driven Development? Goal: To build the right thing the first time.
6. WRITE EXAMPLES (Acceptance Tests) (up front but not UP FRONT ) instead of requirements SPECIFICATION BY EXAMPLE To do this we: 1. Given muppet < Animal > When measuring < Craziness > Then return < 10 > Given muppet < Animal > When < Drumming > Then return < Phenomenal Skillz > Given muppet < Animal > When < talking > Then return < Grunt >
7. TEST AS SOON AS POSSIBLE in collaboration with the developers and customers 2. To do this we:
10. ANOTHER EXAMPLE User Story: As an employee I want to receive overtime pay a standard wage per hour for the first 40 hours worked 1.5 times their wage for each hour after the first 40 hours 2 times their wage for each hour worked on Sundays and holidays For each week, hourly employees are paid:
11. (40*$20) = $800.00 a standard wage per hour for the first 40 hours worked
12. 1.5 times their wage for each hour after the first 40 hours (40*$20) + (5*$20*1.5) = $950.00
13. 2 times their wage for each hour worked on Sundays and holidays (40*$20) + (8*$20*2) = $1,360.00
14. (40*$20) + (8*$20*2 *1.5 ) = $1,520.00 *1.5 2 times their wage for each hour worked on Sundays and holidays
16. “ An attempt to avoid this ambiguity by writing everything down often leads to a document of the type Winston Churchill was working on before he was Prime Minister. Mr. Churchill described it as follows: ‘ this document, by its very size, ensures that it will never be read.’” - Allan Shalloway in “The Role of Quality Assurance in Lean-Agile”
19. What is Value Stream Mapping? Value Stream Mapping is a tool, originating from lean manufacturing used to visually analyze the flow of materials and information currently required to bring a product or service to a consumer.
20. When Would I Use Value Stream Mapping When you are looking to understand and improve a process.
21. A Question to the Audience By a show of hands Who is familiar with Swim Lane Process Maps?
22.
23.
24. A Question to the Audience By a show of hands Who is familiar with Value Stream Maps?
The stuff that QA and the customer does before saying it is done. Functional Testing Acceptance Testing Not Unit Testing We’re not talking about TDD (Test Driven Development) today. Although related, TDD applies more to design, flexible code and unit testing. We’re talking about testing at a higher level – customer, QA, etc.
Happy customers Remove frustrations
Makes requirements less ambiguous – an example later GWT example shown, but lots of ways to do this – start with your existing test case formats and see what works for you. If you can’t do the rest of ATDD, do this! A great place to start.
Catches misunderstandings early so they aren’t duplicated throughout other user stories Improves communication between QA and developers and customers (whole team!) Reduces the time spent writing, reading, understanding, arguing items in a defect tracker When we test, we execute the examples together that we wrote earlier
To prove early that the system works as expected and eliminate the waste of rework Requires and investment time up front required to write the tests – pay off is later Regression testing effort disappears (click a button) Come to my presentation tomorrow for more details
To prove early that the system works as expected and eliminate the waste of rework Requires and investment time up front required to write the tests – pay off is later Regression testing effort disappears (click a button) Come to my presentation tomorrow for more details
example courtesy Allan Shalloway - The Role of Quality Assurance in Lean-Agile
An example using FitNesse (again, more tomorrow) We run this test against the code and see it passes!
Now with some overtime
Now with overtime and holiday hours
Show example in FitNesse here. This example is Green, the last example is Red, until we correct it. Add Given When Then to this
Putting it all together – this is what your executable requirements document now looks like . Complete traceability Push button testing and regression now exists Can replace all business logic in your requirements document Can replace much of your bug tracking effort
- Tell own FitNesse experience here
- Tell own experience here…
Isn’t Value Stream Mapping the same thing as creating a Swim Lane Process Map Diagram?
This looks too complicated
This looks too complicated
&quot;Intellect - Do we fully utilize the talents of our associates? Can developers do other tasks? Transportation (data/materials) - Do we re-key the same information into more than one system or database? Over-production - Do we code more features than are actually are used? Motion (people) - If we co-locate our work teams, would we spend less time chasing each other down? Defects - How much time/effort do we spend making changes or correcting errors? Over-processing - How many approval steps / sign offs would our customers be willing to pay for? Waiting - Is any value added to a project while it waits for resources? Inventory - How many different projects do we work on at the same time?&quot;
Unrealistic deadlines Communication deficit . Scope changes Resource competition Uncertain dependencies Failure to manage risk Insufficient team skills Lack of accountability Customers and end-users are not engaged during the project. Vision and goals not well-defined
Miss Piggy’s definition of value was to sample one piece of cake, surprisingly not the whole cake. This means if the cake could be cut into 10 pieces at the most 9/10’s of a process step may be considered waste (Non Value Add). You’ll notice that it took ten minutes to gather all the requirements of the cake and in fact all of this time could have been value added, although perhaps spending more time upfront may have help improve the quality of the requirements.
Miss Piggy’s definition of value was to sample one piece of cake, surprisingly not the whole cake. This means if the cake could be cut into 10 pieces at the most 9/10’s of a process step may be considered waste (Non Value Add). You’ll notice that it took ten minutes to gather all the requirements of the cake and in fact all of this time could have been value added, although perhaps spending more time upfront may have help improve the quality of the requirements.
Miss Piggy’s definition of value was to sample one piece of cake, surprisingly not the whole cake. This means if the cake could be cut into 10 pieces at the most 9/10’s of a process step may be considered waste (Non Value Add). You’ll notice that it took ten minutes to gather all the requirements of the cake and in fact all of this time could have been value added, although perhaps spending more time upfront may have help improve the quality of the requirements.
Miss Piggy’s definition of value was to sample one piece of cake, surprisingly not the whole cake. This means if the cake could be cut into 10 pieces at the most 9/10’s of a process step may be considered waste (Non Value Add). You’ll notice that it took ten minutes to gather all the requirements of the cake and in fact all of this time could have been value added, although perhaps spending more time upfront may have help improve the quality of the requirements.
Unrealistic deadlines Communication deficit . Scope changes Resource competition Uncertain dependencies Failure to manage risk Insufficient team skills Lack of accountability Customers and end-users are not engaged during the project. Vision and goals not well-defined
Effective Communication –> Reduce Decision Making Delays Buy in
At this point we gather our volunteers and explain the experiment. Explain: First, the teams may not talk from this point forward QA Preferably acted out by a non-QA person (ask who are the testers, and pick a non-tester) Will accept/reject the end product Has a little leeway in accepting – see the ‘test cases’ provided for you. As long as it is pretty close, you can accept it. Aaron and Steve are the customers, so we’ll help you with that. If it isn’t right, please write up the defect on your paper using words or pictures and hand the defect log and the product back to the develop team to fix Ask the QA to person to write good defects – as a dev he/she will know how frustrating an unclear defect is Manufacturing team = Developers There will be a few steps to build the end product These steps are similar to the steps that you create to build software – the classes, database tables, UI, layers, etc. QA won’t test the individual classes and steps, but they will perform functional or acceptance testing on the final product You can pair program if you like, it is up to you to determine the best way to accomplish the task – but again, NO TALKING Team 1 Will not use ATDD – they will test at the end and to simulate this they will not see the ‘test cases’ that QA owns Team 2 Will use ATDD – they will create their test case at the beginning to simulate the effort of automating the tests up front and they will have access to the ‘test cases’ throughout development Both teams Reminder – no talking Reminder – no fighting or blaming – everyone is doing the best they can with what they have been given Don’t copy the other team’s product, the requirements are similar, but the test cases may not be the same Try to be as successful as possible without cheating If you have a defect, don’t throw out the product and start fresh, but fix the defective product We’ll be timing both teams and then examine the results through a value stream before we debrief with questions
Once the exercise is done: First: Ask Questions (time box this) Second: Fill out the value stream maps
Now show and walk through the two ATDD vs non ATDD value stream maps