Where Does Developer Testing End And Tester Testing Begin?


Published on

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.

Published in: Technology

Where Does Developer Testing End And Tester Testing Begin?

  1. 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. 2. Abby Fichtner, Nate Oster 2
  3. 3. 3 Q Game #1 A Software Project Simulation h U Abby Fichtner, Nate Oster T
  4. 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. 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. 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. 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. 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. 9 Lean Thinking Build Only What is Needed Abby Fichtner, Nate Oster Standish Group Study of Software Feature Usage on 2000 projects
  10. 10. Abby Fichtner, Nate Oster Lean Thinking Stop if Something Goes Wrong 10
  11. 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. 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. 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. 14 Abby Fichtner, Nate Oster Self-organizing teams that can adapt quickly & appropriately win!
  15. 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. 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. 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. 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. 19 b Smell: Testing At The End Release! Iteration 1 Iteration 2 Iteration 3 ... E Abby Fichtner, Nate Oster
  20. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 40 K Game #2 A Better Software Project Simulation k hR Q Abby Fichtner, Nate Oster d
  41. 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. 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. 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