7

I wonder what's the common view on the following situation:

  • A bug was found, reported and fixed
  • The bug was verified on a given build and closed
  • After a while (next build; after a few builds) - the bug re-appeared.

Option 1:

  • Reopen the closed bug, add information and continue from there

Option 2:

  • Open a new bug and link to the previous one.

Pros for Option 1:

  • Keep all information in the same place

  • Reduce the bug count and as a result the bug management effort

Cons:

  • This is a regression. Re-opening the existing bug means we don't count this bug as a regression.
  • The bug shows in the "old bugs" list (list of bugs that are opened for more than X days) - and this is incorrect information. It's not really an old bug.

The pros and cons are inverted for Option 2.

What's your opinion? How do you deal with this in your organization? Why this way?

Thanks, Michael

Improve this question
1
  • I want to add one more question to the initial question. How we can avoid this situation of bugs that are fixed to appear again after some time? Thanks
    – alex
    Feb 27, 2017 at 10:29

3 Answers 3

Reset to default
13

I would always go for opening a new issue and linking it to the old one. The defect might look similar in its behavior, but its possible the cause is totally different. If possible let another developer fix this new issue.

The added advantage of having one ticket with all the info is very slim, reducing the defect count is like giving management blindfolds, it is an new issue and people are again wasting time on it. If this happens to often, someone should take action.

It really frustrates me if the same issues come up again and again, this clearly shows there is something missing in the development cycle process, which allows shortcuts and or sloppiness.

If you have recurring defects the following actions might help:

  • Create an automated test for it and run tests on each check-in, to find out when it breaks
  • Do a root-cause analysis and understand how to prevent this from happening in the future
Improve this answer
1
  • +1. Once bug is patched to production and closed, no more status changes s/b allowed. New bug marked as related to old is way to go. Possibly mark as "regression", with impact on priorities and unit testing.
    – Peter M. - stands for Monica
    Feb 11, 2015 at 18:35
4

I would open a new bug, and refer to the old one.

I would also have a conversation with the development team about the duplication, more than just reporting the bug a second time. They might not have fixed the true root cause the first time, or you are doing something that they don't expect in your testing. A conversation could lead to better learning across the board (in addition to the bug report)

Improve this answer
1
  • I would add: Just because it expresses the same symptoms does not mean it's the same bug.
    – pojo-guy
    Jul 9, 2017 at 1:43
0

You can do following in your given situation :

1 - If there are diff. build for ex: First you have test on local server and close bug and if that same bug found in staging / production server in same application then insert that bug as NEW. So that can help us to identify some root cause.

2 - If you closed bug in staging server and getting again on same server for same application then do RE-OPEN it.

As a QA , I do above things. Because mostly developer fix bugs in local server but do mistake in upload to staging server so that is just upload mistake so better we consider as NEW bug for staging server.

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.