1

I've often come across the situation when the same mistake is made in many places in an application. For example, in a web application when the user creates an item and clicks the Add button to save it. If they click the button several times, multiple items are added instead of one because UI wasn't blocked and backend check wasn't performed properly.

How to create bug tickets in such cases? Here are the solutions I could think of:

  • create one single bug ticket and list where the situation occurs
  • for every case found create a separate ticket
  • when finding the bug tell the development to pay attention, wait till they are finished and test again
Improve this question
5
  • Do you use something like Jira or Mantis to create/track bugs?
    – David 'the bald ginger'
    Feb 25, 2013 at 10:37
  • @logansama, I think the system is irrelevant, but I had Jira and Bugzilla in my mind (the ones I've worked with)
    – superM
    Feb 25, 2013 at 11:10
  • Sometimes it does. If the available application has the right features or functions then one could choose solution B instead of solution A.
    – David 'the bald ginger'
    Feb 25, 2013 at 11:58
  • Isn't applying the same fix to several areas of your application a sign of a bigger problem?
    – JeffO
    Feb 25, 2013 at 13:22
  • @Jeff O, The fix may be applied on every place or in one single place so that it effects all areas, depending how the system was designed
    – superM
    Feb 25, 2013 at 13:25

4 Answers 4

Reset to default
1

Recommendation is to create a single bug record. Within the bug, you have 2 choices;

  1. You can note only the specific occurrences found and/or have random checks of several areas to determine scope of the issue.
  2. List all of the areas of the application that have similar behavior and note if they have been tested for the bug. Dev can start on the first areas found, while QA continues testing additional areas of the application. Just be sure they communicate and coordinate on any additional areas found.

The general rule of thumb is, if the bug is most likely to be due to the same cause and require the same fix, then create a single bug. If while diagnosing or fixing the issue, the developer or tester finds different causes/fixes, then the developer or tester is responsible for splitting the bug.

Note that part of your process should also be to identify these types of issues and have periodic meetings with the development team on the top issues. As a team you will then need to decide on training, more thorough unit testing or some other requirement in order to effectively address the issue cause.

Improve this answer
2

In that case I would create one bug, and in it, list all the areas where the issue should be fixed.

With things like this it makes sense to group them together as one work package. The developer responsible can then fix them all relatively easily if it is one repeatable fix.

Improve this answer
3
  • 1
    You could also create several bugs and link them internally - it's almost the same, but e.g. for test cases you can directly relate to a bug per place and test.
    – mhr
    Feb 25, 2013 at 10:24
  • @Ozz, if there is one bug, but the issues must be fixed by different developers, won't this approach create difficulties?
    – superM
    Feb 25, 2013 at 14:35
  • @superM yeah, it would, I didn't make it clear, but for me it makes sense for 1 dev to fix all the issues.
    – ozz
    Feb 26, 2013 at 13:37
2

Talk to the development team (or even better your development team mates), how they prefer it.

The bug(s) are in the end work items for them, so their opinion is important.

Technically both options (and the third, having one 'super bug' with all the occurences as 'bug minions') are pretty much the same. The important part is here to make clear

  • what is the bug
  • where & when does it occur? On one page, on all pages, on many pages?

The rest is more psychology than anything else. I have seen a review that on reviewing a document made a review comment about a wrong formatting of headers separately for every single header in a 100+ pages document. He didn't made friends with that.

But if the bug has get fixed seperately on lots of pages and that takes maybe 3 hours per occurence a separate bug might be considered a nice thing, because it allows to check of progress in a reasonable fashion.

So to wrap it up: Talk to the team.

Improve this answer
1

A parent Task or Story to which separate bug logs are linked to.

So that responsibility could be shared in fixing various occurrences of the issue. Work load and effect on a project commitments can also be shown if more and more bugs are logged against the main log.

If the guilty pary is made the OWNER of the parent story (in Jira for example) then they could be notified of every bug added and they can then be fully aware of what broke where AND their progress in fixing the issues can be tracked.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.