Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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
share|improve this question
    
Do you use something like Jira or Mantis to create/track bugs? –  ddtpoison777 Feb 25 '13 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 '13 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. –  ddtpoison777 Feb 25 '13 at 11:58
    
Isn't applying the same fix to several areas of your application a sign of a bigger problem? –  JeffO Feb 25 '13 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 '13 at 13:25

4 Answers 4

up vote 1 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
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. –  mri Feb 25 '13 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 '13 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. –  jmo21 Feb 26 '13 at 13:37

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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