Ideas for handling QA and Testing Tasks with the Rapid Board

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.

1 answer

1 accepted

This widget could not be displayed.

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.

Thanks for the tips. The card colors will be difficult because I'm already using card colors for assignees. I'm pretty sure I can't do both. I have a pretty large group and when we plan our sprints we try to load up each developer evenly. Since the plan mode doesn't allow us to easily filter or sum up by assignee, I use colors to visualize who has what. Our developers work in specialized areas so we need to do this. I know that's not truly "agile", but thats a discussion for another day. :)

I will investigate the plugins. Thanks for that.

Thanks for the tips. The card colors will be difficult because I'm already using card colors for assignees. I'm pretty sure I can't do both. I have a pretty large group and when we plan our sprints we try to load up each developer evenly. Since the plan mode doesn't allow us to easily filter or sum up by assignee, I use colors to visualize who has what. Our developers work in specialized areas so we need to do this. I know that's not truly "agile", but thats a discussion for another day. :)

I will investigate the plugins. Thanks for that.

That's interesting. I currently using them for assignees. If find it useful when visualizing everone's status at a glance. I would hate to lose that. Maybe the rapid board should have a feature to switch swimlane configs on the fly. What would be harm. It's strictly visual. Though, to do it right, the config portion would need to allow for separate named custom swimlane configs. THis way admins could construct a few "views" using custom swimlanes with JQL. The user would then have the option when viewing plan mode to chose "by Assignee", "by Story", "custom 1", "custom 2", etc. That may address lots of issues in one feature.

That is a good feature request. Create it here - https://jira.atlassian.com/browse/GHS-7400

Till then, copy the board and modify only the swimlane configuration for achieving the view you looking for.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted yesterday in Jira

Atlassian Research Workshop opportunity on Sep. 28th in Austin, TX

We're looking for participants for a workshop at Atlassian! We need Jira admins who have interesting custom workflows, issue views, or boards. Think you have a story to sha...

45 views 2 2
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you