Stubbleblog

(WARNING: This is another bloglines link dump surrounded by poorly disguised context!)

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).

Odeo just finished week one of Scrum, our new engineering and product development methodology. In Scrum, development is focused around month-long Sprints with the goal of delivering as much production-ready functionality as possible. It’s a management dream, engineers are constantly sprinting all-out and releasing massive amounts of features. No more worrying about motivation or snickering about herding cats. Engineering at full throttle. Hurray for management.

The top question from Odeo-ers hearing about Scrum was, “How much rest do we get between Sprints?” Normal Scrum methodology finishes the Sprint with a wrapup meeting, then the next Sprint starts with an all-day planning meeting, then it’s back to coding. In our case we’ll also have a weekend between since we’re doing Scrum on a 28 day cycle. So that’s four days of rest (non-coding) one of which is an all day meeting.

I guess that does sound intense.

I’d been thinking of Scrum as a marathon, as a way to keep focus between mile markers. You focus on one goal for four weeks then, take a refill of requirements, then settle in for the next four weeks.

Two problems with that. First, it’s called a Sprint so you’ve got to expect people to get pretty intense about effort and expectations. Second, it leaves engineering almost no time for context switching.

The latter is pretty important to me. We’re a small company. We rely on engineers making smart decisions and contributing feature ideas. Back-to-back sprints clearly doesn’t allow for this. What to do?