Agile Testing Overview Redux
August 11th, 2008
Filed under Agile, Presentation, Publications, Ruminations
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, 9Mb) identify 9 principles and 6 concrete Agile testing practices. Enjoy.
3 Comments
Leave a Comment
Because of the rise in blog-spam, I've turned on comment moderation. If it takes a while before your comment appears, I hope you understand.
Moderation Policy: I approve substantive comments. I reject ads. And if I don't know whether it's substantive or advertising, it sits in my moderation queue until I get sick of looking at it, at which point I reject it, kind of like the questionable meatloaf in the fridge. But please be assured that I think long and hard before clicking that reject link. I really am grateful for every comment any human takes the time to make. (Spambots, not so much. But if you're reading this, you're probably human.) So please contribute to the conversation...
Aug 12, 2008
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.
Aug 14, 2008
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.
Sep 18, 2008
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.