Tags for this, tags for that

It’s tempting to use short mnemonic text tags in the summary field of your bug tracking system - you know, a tag to indicate that this bug only appears in a short-lived branch, or applies only to a specific patch to a particular customer - the uses are endless.

Don’t do it. Just stop. The reason is simple. Each time you ask the other members of your team to apply some arbitrary tag to certain issues in the bug tracking system, you devalue your bug tracking system.

Why? Because you’re probably misusing your bug tracker’s search feature. Chances are the members of your team are already assiduously storing the information that you need; branch, build number, version, product, component - it’s probably all there. Spend a bit more time figuring out how to construct the search you need - you probably don’t need that extra free-text field!

If you realise you don’t need that field after all, you’ve just saved your team members and yourself a bunch of hassle. Think about it; You can trust folks to accurately choose an option from a drop-down list, especially if it’s a required field, but if you ask folks to add a tag like AcmeCorp” to their bug reports, how many of them will remember to do it? How many of them will spell the tag just the way you expect?

When you attempt to search on the tag, you won’t be able to trust the results you get back, because Ted spelled Acme’ as Amce’ and Diana just forgot to add the tag. What’s the point of that? Just learn to use your bug tracker’s search form like a pro.

April 6, 2010


Previous post
“…like watching paint dry” Colleagues who volunteer comments like “testing is more boring than watching paint dry!” make me laugh. To me that displays an astonishing lack of
Next post
Testing luminaries This post has moved across two blogging platforms during its life. I preserve it here as a snapshot of my thinking about testing at the time I wrote