Traditional software development usually calls for dedicated QA. When I went to Odeo I knew that the engineers there wanted to work in an agile environment. But Odeo had also just hired a traditional QA person coming from a big-software QA group. I’d never heard how people integrated dedicated QA into an agile group so I went hunting for relevant blogs. One that I liked was Agile Testing by Grig Gheorghiu.

Grig’s writing is skewed toward Python but there’s still plenty of gems for the rest of us. Here were the links I had bookmarked in blogines:

Useful tools for writing Selenium tests
Discussion of tools that make it much easier to work with Selenium, a program for writing GUI-based testing for web apps.

Extreme Programming and QA With Kent Beck
A pointer to this QA Podcast interview.

Xooglers – A Blog By Ex-Googlers
Not testing related, but sometimes it’s good to see how and how far a person strays from their blog subject. These are ex-google guys commenting on google on a google-owned blogging platform.

I’m still not entirely sure what the role of dedicated testing is for an agile group. When you’re iterating the product design quickly I think the testing you want is all automated, so that you know quickly if you’ve broken something important (quickly being within 5 minutes). But after you’ve gone through several months of quick product iteration I think you want a thorough QA pass to mark all the rough edges. So either the engineeers the write automated tests as they go and then you bring in contract QA at the end or you hire someone who can do both.

This might be a good time to mention that Rabble, formerly of Odeo, is writing a Testing Rails blog (as well as a testing rails book for O’Reilly).

Related Posts:

• Tyranny of the Sprint
• Done, Done and Ready, Ready
• Lessons Learned Doing Time Boxed Development