Who is responsible for testing?



If I were to ask you, “Who is responsible for quality?” you’d likely answer, “Everyone.”  But, if I were to ask you, “Who is responsible for testing?” would your answer be the same?


This afternoon I attended a tutorial session entitled Agile Testing for “Traditional” Testers and Agile Team Members hosted by Lisa Crispin and Anko Tijman.  The goal of the session was to introduce non-agile testers and non-tester agilists to the concepts and techniques of agile testing.  I took several things away from this session:



  1. Everyone on an agile team is responsible for testing!
  2. Yes, even the developers!
  3. Yes, even the customer!
  4. Everyone on the team is also responsible for test automation, as well.
  5. Unit testing provides the highest return on investment in terms of lowering defect counts.
  6. Acceptance testing just beneath the user interface provides the next highest return.
  7. User interface testing, although brittle, can provide return in some situations.
  8. Exploratory or context driven testing is commonly used on agile teams to leverage a tester’s knowledge of how things are likely to break.
  9. Measuring progress can be as simple as counting your tests every day and plotting the numbers on a big, visible chart.

At the end of this session, Bart Hsu (of MSN) and I invited Lisa to come speak to a joint meeting of our respective user groups.  As it turns out, Lisa has never been to Seattle.  We’ll follow up with her after the conference to see if we can really make it happen.  I’ll keep you posted – or, you can watch the Yahoo! mailing list for the Seattle XP group:  extremeprogramming-seattle.

Comments (1)

  1. Agent000 says:

    [deep sigh] Oh to be in a group that bought in to this! We (the "testers") continue to fight towards this. So far, we’ve managed to get to the point of code reviews of unit tests.

    In fact, earlier in our project we were heavily on the side of "everyone accountable for testing" and it was going wonderfully! We (the "testers") were highly confident of a quality release. As our team size grew by leaps and bounds (don’t get me started on the topic of increasing team size), we gradually lost much of this level of accountability as new people brought old ways of working back to dominance.

    I’d love to see/hear approaches from people that have managed to complete this transition.

Skip to main content