Agile Testing Overview Redux

By on August 11, 2008 in Uncategorized

I recently gave my Agile Testing Overview presentation at a client site.
As I was preparing to do the talk, I dusted off my old slides and realized that they were in desperate need of an update. In some cases, my thinking has shifted a little in the years since I first drafted the slides. But more importantly, the slides focused far too much on drawing a distinction between traditional and Agile methods, and not enough on the concrete Agile Testing principles and practices.
The new slides (pdf, 1Mb) identify 9 principles and 6 concrete Agile testing practices. Enjoy.

About ehendrickson

View all posts by ehendrickson →

Subscribe

Subscribe to our e-mail newsletter to receive updates.

Related Posts:

  • No related posts found

3 Responses to Agile Testing Overview Redux

  1. Al Sargent August 12, 2008 at 10:22 pm #

    Hi Elisabeth,

    Nice presentation!

    To add to the discussion, here is one benefit I’ve been hearing about testing with each build: since each commit contains on the order of a hundred new lines of code, when a bug is found, the “code space” to search for the offending code is very small. This means that the root cause of the bug can typically be found fairly quickly — there’s only ~100 lines of code to search through, not ~1000 or ~10,000. This in turn increases the bug fix velocity, which in turn improves overall development velocity.

  2. Bruce August 14, 2008 at 12:56 pm #

    Hi Elisabeth,

    My concern with agile testing has always been around long-term regression testing, i.e. doing regression testing 12 months down the line when a new feature is being added and all the original developers and testers have “left the building”.

    From your slides I take it that you are proposing automated regression tests, and only at system level. I agree that regression testing can be focussed at system level against observable outcomes, but I am not sure that these kinds of tests can always be automated. This is especially difficult when multiple systems are involved in the end-to-end process with multiple user interfaces.

    I believe that there is still a need to clearly document and manually run system-level regression tests for future maintenance.

  3. Darin Archer September 18, 2008 at 2:30 pm #

    Elisabeth, I just finished watching your presentation on Google video and would like to see additional direction on Bruce’s comment above. Much of the agile discussion seems to focus on Release 1. The challenge is what to do with R1+n. I’d like to know what you have employed to track and maintain some of the manual functional tests such that another team member could execute them in the future or in your absence.