I've used a wide variety of test management software over the past 20 years or so - minimal (Pivotal/Trello/Excel/Google Sheets), behemoth (Quality Center/Jira), open source (Bugzilla/Mantis/Redmine) and comically named (BugHerd/FogBugz). I'm mainly looking at the bug tracking aspect of these tools, as that is what I've been involved with most - if you've stumbled across this article while trying to decide on a tool to use, please bear in mind that a lot of these tools can do much more besides. [Side note: be wary of a developer/project manager pushing for a change to a new tool, it may be your current tool already does what you need, either with a bit of configuration or a change in the way its being used. It may be you can change the process without the overhead of changing the tool.]
All bug trackers have one thing in common - it's not what you've got, it's how you use it that counts. Here are some observations on how to get the best out of your tool. (N.B. I've tried to keep the terminology non-specific but I may occasionally lapse into the terms used by a particular tool, most likely Jira, please substitute in your own preferred terminology where necessary)
All bug trackers have one thing in common - it's not what you've got, it's how you use it that counts. Here are some observations on how to get the best out of your tool. (N.B. I've tried to keep the terminology non-specific but I may occasionally lapse into the terms used by a particular tool, most likely Jira, please substitute in your own preferred terminology where necessary)
- Instant recognition: this is the absolute key for me. When you look at an issue, it should be immediately obvious what is currently happening. No need to read comments, ask the person it's assigned to or cast runes - in most cases the assignee is the person that needs to perform an action on the issue, and its status (or position on a scrum board) tells that person (and everyone else) what that action is. Nothing "ready for test" that hasn't been deployed; nothing closed that hasn't been tested. A key test for this is to imagine a new resource being swapped in for a current team member - they should require minimal handover to understand what their current workload is.
- Keep up to date: if your defects don't reflect the current status of development/testing it will end in confusion and delay; testers may be waiting for items that are actually already deployed and two developers may have picked up the same piece of work. It also throws any estimations of how long is left out of the window, and the time required to get everything back in order will increase the project administration overhead.
- Simple transitions: an over-complicated workflow can make it difficult to determine what to do with an issue when you done with it; this can lead to people taking shortcuts or implementing their own rules, which inevitably breaks the ability for others to know what state an issue is in. I recommend keeping the options at any particular point down to 2 or 3, and being careful with naming of actions/states so that it's easy to choose the right option. Again the handover test applies - you shouldn't need a half day course to understand how to move an item to the next stage of the workflow.
- Restricted privileges: most actions are not aimed at most users; there will only be a small subset for the different user types which will vary role by role. It's much simpler for users if they only have to make a choice from a small set of relevant options. It is also worth having some sort of "super-user" that has the ability to drag an issue between any two states - occasionally issues need to be reset to the starting state and it's better if one person can do this rather than multiple participants having to co-operate. Plus it stops issues from getting closed without being tested.
- Link issues: the ability to link issues can be very powerful - grouping similar defects together, linking stories with associated bugs, and indicating when things need to be fixed in a particular order. Some tools have specific functionality to do this, others may require a bit of lateral thinking (naming conventions or labels can achieve the same effect). You can also use this to archive rambling issues - where a chain of comments becomes unwieldy, open a new issue with a brief summary of just the relevant points, close the old one and link them.
Comments
Post a Comment