Tag Info

Hot answers tagged

60

To a software team, a bug is a software problem that needs to be fixed. Not all software problems need to be fixed. Updating software is expensive. Blizzard is telling you that your problem is an edge case. In other words, the edge case problem you discovered is not necessarily something they tested for or otherwise care to account for. Fixing the ...


60

Well, it's pretty simple: not all exceptions are bugs (and similarly, not all bugs manifest themselves as exceptions). As example of an exception that's not a bug, if you're reading a file from a USB drive and someone yanks the drive out of the socket. That's going to raise an exception (in most languages that support exceptions, that is). But it's not a ...


50

In my opinion, it's a good practice, assuming your users have read access to your bug database. There are lots of times when people are waiting on a certain bug to be fixed in order to decide when to upgrade. I think what's frowned upon is only citing the bug id and nothing else. You should always also supply a description that is understandable without ...


42

It takes too much time to describe issues in it. This discourage its usage. If you can't even describe a bug how can you begin fix it? You create a place to keep your bugs. And if there is a place for them, people usually don't care too much about fixing a bug cause they can put it there so that someday someone can fix it (or not). That is a ...


41

The preference you observe looks like a natural consequence of recommendation clearly stated in GNU Coding Standards. It suggests to report bugs by email, as you can see in below quote (I marked bold the part that directly addresses your observations): 4.7.2 --help The standard --help option should output brief documentation for how to invoke the ...


36

You should log every change you make to your system. There's nothing wrong with logging it after the event - as long as you link the bug report to the change number. Then if anything ever goes wrong you can track back to the bug and find out why you made the change you did. In the vast majority of cases you are right and no one will look at these ever ...


34

You could define different groups of labels like issue types, issue priorities, issue statuses, version tags, and maybe more. In order to be able to see instantly to which group a label belongs to you could use a naming convention like <label-group>:<label-name>. Using such a naming convention should make managing Github issues much easier and ...


33

If it was verified and closed, and worked for a while, and then appeared again after something was changed, then it's not the same bug. It may manifest itself similarly as the old bug did, but its cause may well be different. So it's not the same bug. So I would open a new one, with a link to the closed bug.


31

There are (at least) three different ways a team could work. Choose the one that works for your team. 1. Detail vs. High-Level Overview Use the issue tracker to keep track of individual tasks. Use the card board to maintain a big picture of the major features, as a summary of the tasks in the issue tracker. 2. Bugs vs. Features Use the issue tracker to ...


29

Triage comes from medical jargon - it is the process of prioritizing patient care. When used in the context of bugs it has a similar meaning - determining the priority of a fix. So, untriaged bugs are those that have not been assigned a priority yet.


26

What I'd do (and have done in the past) is create a new bug (to give it relevance), note the possible/new fix, and link to the old one for historical reference/tracking. it also depends on the bug... that bug might be a "feature" now, or have well-established work-arounds that people have been using for 2 years that would be broken by a fix. Basically, ...


25

Nuances like that matter if you consider issue tracker as a means to communicate the status of problems that were reported in the project. For that purpose, it makes sense to invest some effort into ensuring that bug report is easy to read and understand. This situation gets much less confusing if you look at it from a perspective of a tester. If your team ...


23

Work arounds As ChrisF suggests, the pragmatic short term solution may be to use the pause and resume trick, but you have to talk to your customers to know what your priorities should be. For example: If the fault trashes a £1000 part or causes 4 hours of downtime once a week, while the pause-resume fix reduces production by 1%, they will probably prefer ...


23

With Git, in particular, there is a simple historic reason: Git was started by Linux hackers for Linux hackers, and it uses the same development model and tools as Linux itself does. Linux, however, is older than the WWW, so, when Linux was started there simply were no web-based issue trackers, because there was no web! As a consequence, the Linux community ...


22

So how can I advocate bug tracking software to ease the work of the developer ? Given this statement: the spreadsheet allow them to have a more highlevel view of the state of the project as they can see how many bugs are open with a quick glance. you need to be looking at systems that have reporting tools that effectively allow the creation of ...


22

I think the Joel test is up to date - it's as up to date as much of the other software writing that's "timeless". Doing product development (which includes software development) without a spec is just madness. How do you know where you want to go? There's only one point I'll make about writing a spec (I don't actually think Joel's specs are very good... ...


21

This kind of reminds me of the cat in the microwave, specifically the case of Mrs. Smith in 1983. The point is, you expect the product to work in such a way. Mostly because a number of similar products work like that, i.e. if you minimize them for hours and then open them up, they work (although the opposite is not as uncommon as you might think). Mrs. ...


20

Your bug tracker is for your convenience, not your customers'. If you can't be bothered to take their phone or email issue and enter it yourself, how do you think they feel? You need to be able to enter issues and assign them manually to a client. Then when they call in with an issue you can say, "Thanks for reporting that! I'm going to enter it into our ...


20

Like everyone else has mentioned, it depends on the company or house rules of the team but according Joel's post: Painless Bug Tracking Bugs should be closed by the issuer of the bug to make sure that the bug is indeed fixed. So in your case, should a developer close the ticket? Yes, if the developer is the one who raised the bug ticket.


19

The reason is they don't grok why they should be updating the issue tracker, apart from the fact that you say so. Why is that? My guess is that updating the tracker doesn't affect their job in any meaningful way, so the solution is probably to implement a tracking system which actually helps them do their job better.


17

The GitHub issue tracker is quite flexible. There is indeed no priority, nor ordering. It revolves around three major pillars: Assignments, labels and milestones. You can "tag" issues with labels you create (in a similar way than Gmail labels). For instance: "bug", "feature-request", "todo", "question", ... One issue can be tagged with different labels. ...


17

This is quite common. We use this in our team. For Every production defect, the developer must add a note on the root cause of the problem , add a failing unit test and add a test impact analysis before the ticket can be pushed to dev state to check in the code. I don't think this has a specific name except that general "regression testing". This is very ...


17

More important than filing a bug report is to create a test case that will trigger it. If it takes only two minutes to fix a bug, how quickly would you forget about it? Create that test, fix the bug, and it won't raise its ugly head again. The test case is a living bug report, in the sense that no-one has to browse through a bugs database to evaluate what ...


16

Typically I do not like to view "code improvement" activities as a seperate assignable task because code improvement itself never directly brings you closer to completing user stories or requirements. This is why code improvement tasks will always be such low priority that they never get assigned. I see code improvement as a constant, something that every ...


15

Open a new bug, always. Why? Suppose it turns out to be identical to the previous bug, and you've released the fix for the previous bug. Your release notes will document that "Fix Bug XXX." From the point of view of issue tracking and making the release notes clearer, it is preferable to refer to the new bug "Fix Bug XXX+1 (which was similar in cause and ...


15

Thank them for bringing it up to your attention. Reply back with the defect number from the bug tracker. Yes, that means you need to enter the bug yourself. Verify that you have all the details you need to recreate the bug. Bonus points if you can give them an estimate of its priority and when you might be able to fix it. It's also fair to explain your ...


14

I am rather surprised that nobody so far has recommended the use of a wiki for tracking requirements. I've found it to be an almost perfect system, because: It allows people to collaborate on the requirements and makes this aspect highly-visible; It enables you to easily keep the requirements up to date as the project progresses; You can go in and see the ...


14

I would strongly suggest that management reconsider trying to track things in this level of detail. It's going to be inherently subject to gaming. I've seen clients attempt to do something similar but at a group level rather than at an individual level. What inevitably happened was that there was a strong incentive for each manager to get their group's ...


14

Plain and simple, an exception is not (always) a bug! An exception is thrown (or should be) when something exceptional happens. If there is a problem with my hard drive and a file cannot be written, that is not a bug. That is a failure of the hardware. A bug is generally a result of bad programming. If an application does something that is not expected as ...


14

If you use a source control tool, then you can describe the bug you fixed in the commit description and that is usually sufficient documentation for super-small, trivial bug fixes. Furthermore, if you use a bug/feature tracker that is fully integrated with your source control and repositories, like FogBugz and Kiln, you'll be able to use the global search ...



Only top voted, non community-wiki answers of a minimum length are eligible