My opinions on integrating QA into XP and possibly other agile processes.

---

The first way to integrate QA/test is to get them in on the planning meeting. When the customer is describing a story that you are writing down, ask the QA engineer "how would you test this?" If it's a web application with user input, the first thing they may come up with is to make sure form fields are validated properly. Make a story for that and estimate the difficulty (points) for that story. Maybe suggest that the JSON parameters in the AJAX request should also be validated. Some QA folks may need to be coached in hearing a story or seeing a UI sketch and coming up with things they might test or suggestions for usability improvements, etc. Don't expect an exhaustive list -- inspiration may strike them later, and they should be encouraged to come work with the coach/tracker when a new idea hits them. One way to think of it is test-driven product definition.

The major reasons to do this are two-fold. First, XP is all about doing the simplest thing that could possibly work to satisfy the story (which should be the smallest slice of functionality that provides business value). Often, this doesn't include peripheral niceties such as form validation until the customer specifically requests it in a story. When QA files their first bug about something that was requested but hasn't been implemented yet, or the customer didn't request at all, this can sometimes cause some friction in the team. QA should be telling you things you don't know -- not things you already know. Second, by explicitly capturing these expectations in stories and scheduling them, they count for points when measuring velocity. Many agile projects experience a downturn in velocity once they introduce QA to a given project because of the aforementioned bugs not counting as points in most agile processes. Integrating QA in the way suggested can help even out velocity over time.

Having stories that would otherwise be bugs allocated and estimated up front and explicitly scheduled into an iteration (or not) by the customer is an incremental improvement and a great start to integrating QA. When I was QA Manager on Hailstorm 3.0, I spent a great deal of time with the product manager making sure the UI interaction was decent for the targeted users. He would make a mock-up in an image manipulation program, then we would count the number of mouse clicks and/or keyboard shortcuts to go through the top 5 use cases in the two user roles we were targeting. It definitely improved the product, which won Best of Show at Networld+Interop that year (2002). It was also time well spent from a QA perspective, much better than spending a week in SoftIce setting physical memory breakpoints to debug a double-free in a C++ destructor .

I'll write another article in this series soon, but let me know your thoughts on this first piece!

Discussion: showing all 0 messages

(No messages)

>

Post a new message:

---