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. 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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Use Swimlanes.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
1. How do I define colours for a specific story ready for testing? What I found on Jira was some colours templates that I can change only the colors for each IssueType, Assigne, etc.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.