Ideas for handling QA and Testing Tasks with the Rapid Board

Mark DeMichele

My team has developers and dedicated testing/qa people (acutally one person right now ). Currently, our work flow for our stories is something like this.

To Do->In Progress->Ready for Test->In Testing->Done

I made columns for each of these in our rapid board. When a developer complete's his story, (based on the honor system), he will move the story to Ready for Test or Done since some stories (in our case) are not really testable by the QA people. The QA people monitor this "Ready for Test" column and will drag a user story to "In Test". If it passes, the QA person will move it to Done, or back to To Do if it fails. This is working ok for us, but I can't help but feel there's a better solution for this process.

Here's what I don't like about it.

1. Too many columns on the rapid board. On a 24" monitor it's not too bad, but smaller monitors are to hard to read when you show issue details.

2. QA person has no "history" in the project. Issues are never directly assigned to them.

3. Also, we update "Remaining Estimate" daily. So when the developer is "done" (user story "Read for Test") the Remaining Time as we interpret it is zero. If the test fails and the item is reopened, then we have a user story that has 0 remaining time and the developer needs to remember to go in and restimate the time. I'm not sure there's anything we can do about this though.

3. Moving stuff back to "To Do" is a little odd I think. I'm wondering if others do that.

4. Currently the QA person is creating a spreadsheet of failed testcases and is putting them on a server somewhere for the Developer to go and look through. It seems to be that there should be a more integrated approach using Jira/Greenhopper.

I experimented a little with creating a sub-task of the user story and assigning it to the QA person. But then I didn't know what to do with the user story. Leave it "in progress"? Then what? What if the testing task ends up failing. Plus, you seem to be able to move the userstory to done which seems odd if the testing is in progress.

I would appreciate any insight or ideas on how others are handling stuff like this.

Thanks.

Renjith Pillai

1. Use Ready for Testing in the first column and use card colours to identify that they are for testing

2. This is because of the way you are executing Scrum. In theory, at least, you should not be identifying a person as QA or Developer while in a team. As they should be aiming for getting thing that are actually needed to be done to push the team forward, rather than just waiting for things to come to QA stage.

3. Setting a item to zero should be done only after the test is passed. So it should happen like this.

• Estimate includes both efforts for testing and dev
• When the dev finishes then the item is not at zero, the testing effort is still pending
• Daily updates still happen as per the progress of testing
• If it goes back to dev again, it becomes the dev's to update how much is remaining on top of the testing effort
• It becomes zero only when the testing finishes.

4. Oh god, using a spreadsheet which JIRA is like killing oneselves. There are lot of plugins for testcase management for JIRA. Check the market place.