Tag Info

Hot answers tagged

166

Be assertive not aggressive. Always favour saying something akin to "this piece of code is not working" vs "your code is not working". Criticise the code, not the person who wrote the code. Better yet, if you can think of a solution, fix it and push to them -- assuming you have a distributed version control system. Then ask them if your fix is valid for ...


112

If you discover a bug, I can't think of any good reason not to enter it into the bug tracking system, whether you fix it or not. That's what the bug tracking system is for, after all. In some cases it might make more sense to report it to a QA person who has more experience dealing with the system, but in any case the bug should be tracked. It's possible ...


87

Is there a point at which the process gets in the way and becomes an end unto itself? Heavy processes are common, unfortunately. Some people - especially management - religiously imagine that processes produce products. So they overdo the processes and forget that it's really a handful of hard-working, smart people who actually create the products. For ...


79

Characteristics do not equal causes. The new bug could have a different underlying reason, even though it appears to be the same. So, open a new bug and point it to the old one to help the developer.


78

1, but only if it's painless. GitHub for example has a very simple and usable issue tracker with more than enough features for a small team. Bugzilla, Trac or others are good, but they all require hardware, installation and configuration before use, and maintenance is definitely a non-zero expense.


69

Yes always. As a programmer its your job to learn from mistakes. Letting them know mistakes they make will help them become a better coder and reduce their chance of making mistakes in future. BUT do be polite and dont make a big deal of it, we all create bugs every so often. I find a polite email is a very non confrontational way of letting people know.


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

I think all the "yes" answers go a long way to endorsing the idea. But I'm going to throw out the idea that the decision is based on a few questions: How do you want to communicate as a team? With 2 developers, you are now a team. How do you want to communicate? Plenty of agile teams live with in person discusions and white board sketches. But they may ...


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 ...


49

We resolve such issues as 'Obsolete'. This is not a default resolution option in JIRA but it is easy enough to add.


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

We had a very tiny team the first time I used bug tracking software and I was amazed at how much stuff we had been thinking we needed to fix that somehow never got fixed. It's totally worth it no matter how large your team is.


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 ...


38

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 ...


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 ...


35

For small projects, I've become a big fan of Trello. It has such a low barrier to entry, and such high usability, I would use it for any smaller projects. If you want something a bit more complicated-looking and feature-complete, I'd second the suggestions of FogBugz or Bugzilla. Edit to provide more "explanation and context": The most common issue that ...


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 ...


30

How big of a team do you need to benefit from bug tracking software? 1


30

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.


27

Yes. A thousand times yes. Don't even think of it in terms of bug tracking but as ticket tracking. Being able to see all your tasks in tickets has a huge advantage. You can keep a history of a task in one place. You know who worked on it and when. You can be as detailed as saying what was completed on what day for a task. For bug tracking, you can place ...


26

If you just approach them to tell them about a mistake they made then unless you are the best diplomat in the world its going to be difficult for it not to just sound like "Ha! - look at this mistake you made!". We are all human and criticism is difficult to take. On the other hand unless the change is completely trivial and obviously wrong I normally find ...


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, ...


26

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 ...


25

Fogbugz (free individual license) if its a longish project or a simple to do list (using Google tasks)


23

5 bugs = 5 bug reports; the fact that they can all be fixed at once is not QA's concern. in other words, guessing that all 5 bugs stem from the same problem is putting the cart ahead of the horse.


23

The constructive way is to find the bug, fix it and take actions to avoid similar bugs to arise in the future. If it involves explaining people how not to introduce bugs, go for it. Once, I worked in a team where the project manager never told a particular developer that he made a mistake: he organised a meeting with the whole team where he explained that ...


23

You must enter the bugs in the bug tracking system in both cases: when the bug concerns directly the code you are working on, when the bug concerns the code you're not working on right now or the part on which another developer works. This is essential, since the bug tracking system is made to... track bugs. Every bug. If you discover something wrong, ...


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 ...



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