Agile 2009 Workshop presented by Abby Fichtner and Nate Oster. Workshop description: Where Does Developer Testing End And Tester Testing Begin? This is a trick question, right? In agile, everyone works on the same items together, at the same time. Yet, the reality is we’re not all interchangeable cogs. Developers and testers each bring their own, unique skills to the table. The key to effective agile is not minimizing our differences, but building upon the strengths each person brings to the team. Join us for this hands-on simulation and retrospective as developers and testers explore how agile teams build quality into their process, how each member contributes to that quality, and how we can avoid traditional testing pitfalls.

1. A Where q Does
m Developer N Testing n
End X And
B Tester P Testing I Begin g
?
by Abby Fichtner & Nate Oster
Agile 2009 - August 24, 2009
This presentation is licensed under a Creative Commons Attribution-Share Alike 3.0 License

2. Abby Fichtner, Nate Oster
2

3. 3
Q Game #1
A Software Project Simulation
h
U
Abby Fichtner, Nate Oster
T

4. 4
What the gh was that?
1. What dysfunctions occurred in game?
2. Do these occur on software projects in
the real world?
Abby Fichtner, Nate Oster

5. 5
Is this really the best way to
develop software?
Abby Fichtner, Nate Oster
Are these dysfunctions intrinsic to developing software?
Or are they the result of how we companies tend to organize software teams?

6. 6
There has to be a Better Way
Abby Fichtner, Nate Oster
“You will be amazed at how much faster you can go when you make stuff
and defects are caught when they occur instead of being found later.”
- Mary Poppendieck, Google Tech Talks, 12/2006

7. 7
Our Path T a Better Way
o
Review key lean principles
Walk through what this looks like
Game Redux
Abby Fichtner, Nate Oster

8. 8
Lean Thinking
Lean Production Model
Build only what is needed
Stop if something goes wrong
Abby Fichtner, Nate Oster
Eliminate anything that does not add value
Taiichi Ohno, The Toyota Production System

9. 9
Lean Thinking Build Only What is Needed
Abby Fichtner, Nate Oster
Standish Group Study of Software Feature Usage on 2000 projects

10. Abby Fichtner, Nate Oster
Lean Thinking
Stop if Something Goes Wrong
10

11. 11
What happens when we write code without
detecting defects?
Lean Thinking
Get a pile of bugs to fix at the end
Discover misunderstood requirements
Discover incorrect design assumptions
Rework!
Abby Fichtner, Nate Oster
v

12. 12
Eliminate Anything that Doesn’t Add Value
Building features that aren’t needed
Documenting things we don’t need to keep
Lean Thinking
Capturing the same thing 5 different ways
Knowledge Waste
Interruptions
Delays
Handoffs!
Abby Fichtner, Nate Oster
Adapted from “Implementing Lean Software Development”, Mary and Tom Poppendieck

13. 13
When Errors Happen Fix the Process
Most errors are caused by the process we work in, not the individuals
Management overestimates ability of process
“This is a best practice, so it must be your fault!”
Team overestimates ability to overcome bad process
“We are in control, so it must be our fault!”
Insanity is doing the same thing over & over…
Whack 1 person for committing the error
Error pops up again from another person
Abby Fichtner, Nate Oster
The problem is with the Process, not the People!
Adapted from Allan Shalloway, Net Objectives: Lean Online Training Class it

14. 14
Abby Fichtner, Nate Oster
Self-organizing teams that can adapt quickly & appropriately win!

15. 15
Lean Quiz #1
T Prevent Errors, We Should…?
o
a) Tell developers not to write bugs
b) Tell testers to find more bugs
c) Tell customers to be clearer
d) Find better customers
e) Fix our process!
Problem Fix the Process
Abby Fichtner, Nate Oster
Developer bugs Write unit tests to catch them
Customer unclear Specify acceptance tests before code
Customer changes mind Work in short iterations
Demo early & often
Adapted from Allan Shalloway, Net Objectives: Lean Online Training Class

16. 16
Lean Quiz #2
T Get More Done, We Should…?
o
a) Give everyone multiple things to do so they’re
never stuck waiting
b) Define strict rules & precise procedures to
ensure each task is done just right
c) Make our process work for us
Abby Fichtner, Nate Oster
Problem Fix the Process
People stuck waiting Eliminate delays
Tasks done inefficiently Self-organize to tap team’s expertise &
adapt to each situation

17. 17
Lean Quiz #3
T Go F
o aster We Should…?
,
a) Work harder
b) Work faster
c) Remove useless delays
Abby Fichtner, Nate Oster
It’s not about working HARDER or FASTER
It’s about delivering more VALUE

18. 18
Agile Testing Smells
1. Testing at the end
2. Repeating manual tests
3. Using testers as a safety-net
4. Not aligning rewards with goals
5. Programmers & Testers not working to same goal
Abby Fichtner, Nate Oster
b

19. 19
b Smell: Testing At The End
Release!
Iteration 1 Iteration 2 Iteration 3
... E
Abby Fichtner, Nate Oster

20. 20
b Smell: Testing At The End
Iteration 1 Iteration 2 Iteration 3
X
Release! Actual
Release
R Code Test
R Code Test
R Code Test Bug Fix
Abby Fichtner, Nate Oster
Test & Fix Iteration
This agile thing stinks!
b

21. 21
Prevent Defects Poka-Yoke
Design products to prevent mistakes
Compilers prevent language errors from entering software
Supplement builds to prevent application-specific defects
Software still finds ways to fail!
Exploratory testing early & often
Mistake-proof defects in automated tests
Abby Fichtner, Nate Oster

22. 22
Stop the Line
STOP
Organize work so slightest defects identified immediately
Prevent Defects
When problems found STOP and FIX before it compounds
Don’t just band aid
Determine & address root cause
Abby Fichtner, Nate Oster

23. 23
b Smell: Repeating Manual Tests
Waste of testers’ time & skills!
DRY (Don’t Repeat Yourself )
No time to spend months regression testing each change
Spend time doing what you’re great at!
Abby Fichtner, Nate Oster
h

24. 24
Automate Regression Tests
Have tests focus on intent, not implementation
ourself
Push tests as low as possible in the pyramid
Don’t Repeat Y
Exploratory
/Manual
GUI
More business Lower-cost
facing, realistic Easier maintenance
Acceptance Tests
Faster feedback
(API Layer)
t
Abby Fichtner, Nate Oster
Unit & Component Tests
Adapted from Mike Cohn (Automated Test Pyramid) & “Agile Testing”, Lisa Crispin & Janet Gregory

25. 25
Test-Driven Development (TDD)
Immediate Feedback
Implementation Write a
failing test
Design
Helps Us:
Clarify acceptance criteria
Refactor R Make
it Pass
Write good code
Mistake-proof our code
Know when we’ve done enough
Abby Fichtner, Nate Oster
Have courage to continue by providing safety-net
Adapted from “Growing OO Software Guided by Tests”, Steve Freeman & Nat Pryce

26. 26
Acceptance Test-Driven Development
Drives development by specifying conditions of satisfaction
Measure of demonstrable progress
Describe: Short paragraph to describe functionality
Demonstrate: Give examples to demonstrate
Develop: Implement using inner TDD loop
Write a
h
failing test
Write
a failing
Acceptance Test
R Make
Abby Fichtner, Nate Oster
Refactor it Pass
“Tests that encourage communication are the best kind”
- Lisa Crispin
Adapted from “The Art of Agile: How I Use Fit”, James Shore

27. 27
Customer-Driven Development
Focus shifts as team masters test-driven development
Bug detection
Bug prevention
Better ways to capture & elicit requirements
Write a
h D
failing test
E
Write
Demo/
a failing
Acceptance Test
Refactor R Make
Feedback
Abby Fichtner, Nate Oster
Conditions of it Pass
Acceptance
Adapted from “Agile Testing”, Lisa Crispin & Janet Gregory

28. 28
b Smell: Using Testers as Safety-Net
Only Testers can test the whole system
Months of manual regression tests
Programmers rewarded for code “complete”
Testing group’s problem
Too easily degrades into not taking responsibility for actions
Pits programmers & testers against one another
Abby Fichtner, Nate Oster

29. 29
eam Accountable for Quality Automated Tests as Safety-Net
Automated tests let everyone test
Automation “builds in” error detection
Everyone can detect & correct their errors
If a test breaks stop the line and FIX immediately
Provides courage to make changes needed to evolve system!
Without requiring armies of manual testers!
Abby Fichtner, Nate Oster
T

30. 30
eam Accountable for Quality Hold Everyone Accountable for Quality
Customers
D Conditions of Satisfaction
Defining objective acceptance criteria E
Programmers
Internal Quality
Clean code backed by automated unit tests
h
Testers
Abby Fichtner, Nate Oster
Bridging the Gap
Help customers articulate quality needs
Work with programmers to ensure quality needs are met
T

31. 31
eam Accountable for Quality Agile Testing Quadrants
Mostly Mostly
Automated Manual
Business-facing Tests
Tests that critique the product
Tests that critique the product
Tests that support the Team
Exploratory Tests
Acceptance Tests Usability Testing
UAT
Unit & Component Performance Testing
Tests Security analysis
“-ility” tests
Abby Fichtner, Nate Oster
Automated Specialized
Frameworks Technology-facing Tests Tools
T
Agile Testing”, Lisa Crispin & Janet Gregory” (Originally created by Brian Marick, 2006)

32. 32
b Smell: Not Aligning Rewards with Goals
If we work together, we might have a better product & deliver faster
but there’s no incentive for us to take this longer-term view
Programmers: “Completing” code
I finished my task, it’s no longer my problem
Testers: Finding bugs
If there’s lots of bugs, I’m doing a good job!
Everyone: # of tasks completed
Why should I help you? That’s less time to get my own work done
Abby Fichtner, Nate Oster
A h U
A

33. 33
Align Rewards with Goals Measures that Drive Desired Behavior
Focus on what we care about
Delighted customers
Return on investment
Minimizing total cost of ownership
Lean Metrics like Concept to Cash
Expose wastes
Encourage people to work together
Drive good behavior across the organization
Abby Fichtner, Nate Oster
“Implementing Lean Software Development: From Concept to Cash”, Mary and Tom Poppendieck
Dh E

34. 34
Smell: Programmers & Testers
b Not Working T
o Partially done work
ogether
o Missing feedback
o Problems left to compound
Abby Fichtner, Nate Oster

35. 35
esting Concurrent Testing
Pair a Programmer & Tester on each story
Concurrent T
Drive development from acceptance (story) tests
Hold everyone accountable for quality
Demo production quality software to customer at end
of each sprint
Abby Fichtner, Nate Oster
h E

36. 36
For Each Story…
We want everyone working towards a single, shared goal
E
esting
Programmer, Tester & Customer:
Define conditions of acceptance (“Done”) as tests
Dh
Concurrent T
Clarify what’s in/out of scope for iteration
Synergy from different perspectives
Everyone walks away with shared understanding
Abby Fichtner, Nate Oster

37. 37
Building the Stories…
Programmer & Tester have a shared responsibility to complete story
esting
Programmer & Tester refine acceptance tests & start building…
One slice at a time, starting with happy path
h
Concurrent T
Define internal definition of “done”
Tester builds out business-facing tests
Programmer codes functionality, helps automate tests
Tester pairs with programmer to mistake-proof code
Abby Fichtner, Nate Oster

38. 38
Evolving the Stories…
Build upon the synergy of pair’s unique skills & perspectives….
As each slice is coded with passing TDD tests,
esting
Tester and Programmer pair to evolve the story…
Testers do exploratory testing with the programmer
Concurrent T
High bandwidth (side-by-side)
Fix issues real-time and get immediate feedback
Feed new automated tests & next slice to build
Select next slice & repeat until acceptance tests pass
Measure progress against automated Acceptance Tests
Abby Fichtner, Nate Oster
h

39. 39
At the End of the Iteration...
Expect the tests to pass! Because we’ve…
esting
Built quality in through out the iteration
Prevented defects with mistake-proofing
Concurrent T
Stopped the line to fix problems
Demo production quality software to customer
Holds everyone accountable
Helps team celebrate wins
Leads to delighted customers
Abby Fichtner, Nate Oster
h

40. 40
K Game #2
A Better Software Project Simulation
k hR Q
Abby Fichtner, Nate Oster
d

41. 41
Retrospective
1. How did self-organizing change the way we worked?
2. How did changing the way we work change our outcomes?
3. What challenges do you foresee applying these on your projects?
4. Have you seen evidence that these challenges can be overcome?
5. What’s the most important lesson you can take back to your
Abby Fichtner, Nate Oster
project?

42. 42
Agile Tester’s Bookshelf
To learn more about programmers & testers working together…
Implementing Lean
Software Development
by Mary & Tom Poppendieck
Beautiful Teams
Agile Testing by Andrew Stellman & Jennifer Greene
by Lisa Crispin
& Janet Gregory
Abby Fichtner, Nate Oster
NetObjectives online Lean resources:
http://www.netobjectives.com/resources/
See Also
Growing OO Software, Guided by Tests
http://www.mockobjects.com/book/ Bridging the Communication Gap &
Test Driven .NET Development with FitNesse
James Shore The Art of Agile FitNesse posts: by Gojko Adzic
http://jamesshore.com/Blog/Agile-Requirements.html

43. Thank You!
Abby Fichtner Nate Oster
Hacker Chick Technical Director
,
(m) 703.615.3394 Agile Player-Coach
afichtner@atsc.com 703.930.4100 (m)
http://TheHackerChickBlog.com noster@atsc.com
This presentation is licensed under a Creative Commons Attribution-Share Alike 3.0 License