Your SlideShare is downloading. ×
Testing Does Not Equal Quality
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Testing Does Not Equal Quality

1,039
views

Published on

Presentation for SQuAD on May 12, 2009. …

Presentation for SQuAD on May 12, 2009.

Abstract:

In an agile environment, testing alone is not sufficient to ensure quality. Many other factors come into play to ensure true quality. This session will explore the meaning of "quality" and give some examples of how it can be enhanced. Richard and Bob will also explain the principles behind an agile process which achieves a quality product as well as a potential workflow to implement the process. This will include how QA integrates with the team to avoid creating a "mini-waterfall" situation.

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,039
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
34
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Photo: Tug o’ war between speed/value and quality
  • This is the structure/agenda for the rest of the presentation
  • Briefly dig into “valuable” and “now and in the future.” Big idea: quality is about ensuring business value and speed/sustainability.
  • Explain the cumulative cash flow chart, what it means. Wave at how quality might change its shape.
  • The impact of quality on value is clearer if we just look at value over time non-cumulatively. Here’s an example of a value flow for a feature that works as intended, the counterpart to the cumulatively cash flow in the previous slide.
  • straight line at 0 – there’s never any value
  • Less value than the original value flow, and goes up and down over time.
  • Value flow with gaps
  • Increasing value flow with a cliff when the system gets overloaded.
  • We’ve been looking at the value over time of a feature. We can also look at the value produced over time by a team. We normally call this “velocity.”
  • Slightly increasing, pretty stable velocity
  • Decreasing velocity, as tech debt increases the cost of new features over time.
  • Quality is not something you add on top of value. It only makes sense in terms of value now and in the future, as revealed by feature value flows and team value flows. (Flip side of this: Anything we would do in the name of quality that doesn’t ensure value now and in the future is probably waste.)
  • Inspect for quality: PO asks for something. Dev builds what they think PO wants. Test inspects for what they think PO wants. Loops ensue. Sometimes it works. More often, it doesn’t. Build quality in: Use tests as specs. Engage QA/testers with PO and dev at the start of a feature instead of just at the end.
  • Moving testing to the front is good. But if our testing is all or mostly manual, we have a problem after just a few iterations.
  • If you automate your tests as you build them, this iteration’s new tests become next iteration’s regression tests, but you only need to build them once. Also, you give your devs something they can run to ensure that their code passes all the tests before they call their work done. This reduces the loops we mentioned a moment ago.Note, however, automation can’t be much more expensive than manual testing or the whole thing falls apart. This drives tool choice. So does the need to write automated tests against not-yet-existent features. No time to talk about it here, but there’s a reason certain test tools are more popular in the agile community and others are more popular in the waterfall world: your tool can make or break your success with agile testing.
  • Remember, features are in priority order, so the most valuable feature is the most tested feature.
  • We’ve moved testing to the front and started automating our tests. But if it still takes a day or two to get code built and into a test environment, completing a story can take twice as long. If the process is manual and error-prone or if you regularly find defects post-deployment, now you have loops. Add in multitasked RM people who aren’t available when you need them, and your 2 day story easily takes 6-8. In a two week sprint, you’re not getting much done.
  • Transcript

    • 1. Testing != Quality
      Rethinking quality and how to achieve it in an agile world
      Bob Hartman
      Richard Lawrence
    • 2. “How does QA fit into all of this?”
    • 3. Speed/value
      and
      quality
      are conflicting goals
    • 4. Or are they?
    • 5. What is quality?
      How do we ensure
      our software has it?
      How can quality enable speed and value?
    • 6. What is quality?
    • 7. The goal of a software org:Produce valuable software now and in the future.
    • 8. A feature can be modeled with a cumulative cash flow chart
    • 9. Or, we can remove the investment and just look at value flow
    • 10. Value flow for a feature that never works right
    • 11. Value flow for a feature that fails for some users some of the time
    • 12. Value flow for a feature with downtimes
    • 13. Value flow for a feature that doesn’t scale
    • 14. Quality is the foundation of value
    • 15. A team’s productivity can be measured with a velocity chart
    • 16. Velocity of a team with a well-designed, high quality system
    • 17. Velocity of a team with a poorly-designed, low quality system
    • 18. Quality is the foundation of speed
    • 19. Photo credit: woodsy on sxc.hu
      Quality is what ensures: Value now and in the future
    • 20. How do we ensure our software has it?
    • 21. Testing at the end doesn’t work
      Iteration Start
      Iteration End
      Plan
      Dev
      Test
      The Plan
      The Reality
    • 22. What’s really going on?
      Dev
      Test
      The Plan
      Dev to test is really a loop
      Dev
      Test
      The Reality
      Dev expands to fill the available time
    • 23. Build quality in vs. inspecting for it at end
      Dev
      Test
      Plan
      Inspect for quality
      Build quality in
    • 24. Manual testing doesn’t scale
      (or happens in overtime)
      Testing that doesn’t happen, but should
      Regression testing
      Testing capacity
      New feature testing
      Sprint 1
      Sprint 2
      Sprint 3
      Sprint 4
      Sprint 5
    • 25. Automate and get regression tests for free
      Automated tests that are now regression tests
      Testing capacity
      New feature testing
      Sprint 1
      Sprint 2
      Sprint 3
      Sprint 4
      Sprint 5
    • 26. What is really being tested?
      Iterations
      Features
    • 27. Which features need to work best?
      Usage of features in a typical software product
    • 28. But without regression it is different
      Iterations
      Features
    • 29. Minimal regression is a little better
      Iterations
      Features
    • 30. But what will happen where we don’t have regression tests running?
      Iterations
      Features
       = Missed tests, which Murphy’s Law says will lead to defects being missed!
    • 31. Build and deploy processescan kill speed
      DONE
      The Plan
      Define acceptance criteria and automate tests
      Develop
      Package
      Deploy to test env
      Test
      Loops, waits, errors…more time
      The Reality
    • 32. To ensure quality in an agile world:
      Move testing to the front of the process
      Collaborate
      Automate tests (using agile-friendly tools)
      Automate/accelerate build and deploy
      Work on user stories one at a time, all the way to DONE
    • 33. Questions?
      www.agilebob.com
      bob.hartman@agileforall.com
      www.richardlawrence.info
      richard@humanizingwork.com

    ×