Shortly after logging a bug this morning, my business analyst kindly asked, “Is this the same as Bug10223, that I logged in October of 2011?”.
…It was!
Ordinarily, prior to logging production bugs that have been around for a while, I run a bug report query to search for open bug reports by keywords. It takes about 10 seconds to determine if the bug I’m about to log has already been logged. This morning I got lazy (and cocky) and just logged it.
It probably took 20 minutes of my time and my business analyst’s time to create a bug report that already existed, communicate about the confusion, and reject my duplicate bug report.
Look before you Log!
9 comments:
Subscribe to:
Post Comments (Atom)
RSS
It happens very often in big projects (>50 people) where are so many testers, programmers, analysts amd you duplicate some bugs. It's not possible to remember couple of thousand bugs, especially if 300 of it are in open status.
Actually, I am simply asking for my team-mates if they registered that kind of bug or not, because to check all bugs (even by component or status) takes some time. It's ok, if there is free time to do that.. but as we know, we don't have time enough.
What is the best solution? I would like to know, how you deal with this problem? :)
Interesting problem that we often face. What I do is ask my team mates to informally check through chat if any such bug is already open. Of course works for very small teams though (My team is around 8 member qa)
Regards
Rajaraman R
Test Data Management Blog
A friend of mine works as software test engineer, whenever she talks about bugs on computer or programs, I often find myself at lost in the conversations. That's why I researched for sites like this to keep myself abreast or at least familiar with the jargon she uses.
I'm not suggesting that you shouldn't look for duplicates before reporting you own. However, I'd much rather report a duplicate issue than not report a new issue.
You can hash the dupes out later in a review session.
Ken, I agree. It may be better to err on the side of creating a dupe bug report rather than losing it altogether.
bugs4tester,
Thanks for the great question. I think I'll respond with a blog post later this week.
Communication is every thing in projects. I am with Ken on the same page. I would rather have duplicate than an issue that is not reported due to misunderstanding that the bug was not the same as the existing one.
But wait, the bug out of your story is known since 2011 and is still open ? :)
Chéers,
Camal
You can also minimize creating bugs at all. One of my agile teams just creates test case failures. Developers work the failures at the end of the sprint, any failed tests that don't get addressed roll back into the backlog to become defects.
If we dont log the duplicate bug which is same in another web page,there might be a situation that developers look onto to the bugs which are informed to them (in one log) and may not consider to look into again for other pages.
In this situation how to log the bug?
WHICH TOOL U USE TO LOG THE BUGS?