Agile Testing, Uncertainty, Risk, and Why It All Works


Published on

Testing is integral to any Agile development process. This slide deck offers an overview of Agile testing-related practices and explains how they work together to mitigate the most common sources of risk on any project.

Published in: Education

Agile Testing, Uncertainty, Risk, and Why It All Works

  1. 1. Agile Testing, Uncertainty, Risk, and Why It All Works Elisabeth Hendrickson Quality Tree Software, Inc. Last updated April 27, 2010 Copyright © 2010 Quality Tree Software, Inc. This work is licensed under the Creative Commons Attribution 3.0 United States License. View a copy of this license.
  2. 2. What Does Agile Really Mean? Agile software teams… …Deliver value in the form of releasable software at frequent regular intervals (at least monthly)… …At a sustainable pace… …While adapting to the changing needs of the business.
  3. 3. It’s Not Done Until It’s Tested We’re really But what if behind. Let’s just it doesn’t call it “done” and work? move on. It’s not releasable until it’s Done. (Really Done.) Done includes both implemented and tested. And tested means checked and explored.
  4. 4. Testing: Consider Certainty v. Time “Traditional” Release Single Sprint Sequence of Sprints
  5. 5. Illusion Buildup Illusion Time
  6. 6. Four Big Sources of Technical Risk Ambiguity Dependencies Assumptions Capacity
  7. 7. Eight Key Testing-Related Practices in Agile Exploratory ATDD TDD Testing Automated Automated Collective Test System Tests Unit Tests Ownership Continuous Rehearse Integration Delivery
  8. 8. Practice: Acceptance-Test Driven Development (ATDD)
  9. 9. Principle: Tests Represent Expectations I found a great bug! Ummm…and what gave It won’t run on a you the idea that Commodore 64! should be a supported platform? Test Driven practices make expectations explicit and drive out ambiguity early.
  10. 10. Principle: Reduce Test Documentation Overhead ATDD provides leveraged documentation and results in executable requirements.
  11. 11. Practice: Automated System-Level Regression Tests • Are business-facing, written by various members of the team in collaboration • Express expectations about externally verifiable behavior • Represent executable requirements
  12. 12. Principle: Reduce Feedback Latency Latency
  13. 13. Practice: Test Driven Development (TDD)
  14. 14. Practice: Automated Unit Tests • Are code-facing, written by programmers to support the coding effort • Express expectations of the internal behavior of the code • Isolate element(s) under test • Execute quickly and often
  15. 15. Practice: Collective Test Ownership
  16. 16. Practice: Continuous Integration (CI) CI tools do automated builds, execute tests, and report the results Developers practicing CI merge their changes locally & execute tests before checking in
  17. 17. Principle: Red Build Means Stop the Line We can just throw But that will that bug on the pile increase technical with the others. debt & slow velocity. Yuck. If a previously passing expectation fails, there’s a bug. Bugs slow everything down. To keep sustainable pace, fix bugs fast.
  18. 18. Practice: Exploratory Testing Simultaneously… …learning about the software …designing tests …executing tests using feedback from the last test to inform the next (See Jon and James Bach’s work on Session-Based ET)
  19. 19. Principle: Fail Early, Fail Fast Failing late results in panic. Failing early gives us time to fix the problems.
  20. 20. Practice: Rehearse Delivery Until we ship or deploy, we don’t know what will go wrong getting a “Done” system out the door.
  21. 21. Agile Testing Practices Mitigate Risk Continuous ATDD Integration Rehearse Ambiguity Dependencies Delivery TDD Automated Automated System TestsUnit Tests Exploratory Continuous Collective Test Rehearse Integration Testing Rehearse Ownership Assumptions Delivery Delivery Capacity Automated Automated Automated Automated System Tests Unit Tests System TestsUnit Tests