Hot answers tagged

49

As a developer with 15+ years experience, I'd say: please report the bug. I'd much rather have a ticket in the tracking system than a vague memory of a hallway conversation, or an interruption of what I'm working on. As Joel Spolsky put it: At any given time, I can only remember two bugs. If you ask me to remember three, one of them will fall on the ...


34

Issue Reports (Bug Reports) are one of the main communication methods that QAers use. You are creating a statement to your stakeholders - "I have found what I think is a problem, and here's my clear explanation of what it is and how you can see it too. Please look into this". Understand the Audience for the Report It's important to know who is going to ...


22

Yes, by all means - you must write a bug report! In your report, note that the bug is intermittent, and leave comments about your investigation, what you have done to try and reproduce the problem, and any other clues you can think of. Developers may not be able to reproduce the issue, but they may be able to see the bug in the code itself, or add ...


20

It is always a very good practice to start testing as early as possible. By not fully implemented if you mean still under development, then I suppose that is not such a great idea. Yes, you can go for incremental build releases for testing, that might be helpful. When you say that your testers all log the same bugs, well there's your problem! Do you ...


19

As a developer, this is the information I need to solve a problem: Steps to reproduce. Expected result. Actual result. In that order, no more, no less.


17

I think the problem arrives from how you use your VCS: You want to commit your code because you have finished a sub task and want to have it backed up in case of e.g. a hdd crash on your workstation. Your testers see changes in the repo or get an automated build which they test. One solution could be a separate working branch which is work in progress. No ...


16

The severity of a bug is a measure of how important the bug is to the end user: how much it breaks, how badly it breaks things, how difficult it is to get work done with this bug in place. The priority of the bug is a measure of how important the bug is to the development team. This will take into effect the severity, but also the development time and ...


14

In my own experience, I've found that this really depends on the culture of the team or company that you're working with. On a team with good communication skills, and where everyone works together well, you may very well be able to just tell the developer about it, they take a look at it, and say it'll be fixed in 5 minutes. If it's longer, maybe they'...


14

To me this is a perfect example of what happens when effectiveness of testers is assessed based on the wrong KPI, in this case, a number of bugs reported. In the end it will harm testers, developers, relationships between tester and developers and as a result product quality. To me this is wrong KPI and there is been at least two discussions here why is so: ...


13

Only one thing i would like to add apart from Joe's contribution. Don't point out two or more issues in the same bug report. If you feel there appears another different issue when you follow the same steps, raise it separately, otherwise there the chance it get missed.


12

To expand on the link Phil K mentioned. Cem Kaner published a paper entitled "Bug Advocacy" which you can read about in a 100 page PDF at: http://www.kaner.com/pdfs/bugadvoc.pdf. It also forms the basis for the second BBST course. Kaner outlines 4 major points of Bug Advocacy: (quoted directly from page 10.) The point of testing is to find bugs ...


12

Note this is community wiki, please add if you have additional resources. I normally don't answer my own questions, but I thought if I could track down one example, maybe others would get a better idea of what I'm looking for. Lesson 77 out of "Lessons Learned in Software Testing", titled "Nonreproducible bugs are reproducible", has a short, non-exhaustive ...


11

It's a rather difficult problem to solve, since bug reports are often written from the point of view of the observer, rather than the root cause. Tags/keywords are a good idea. One thing I do is attempt to have the bug report analyzed quickly by the relevant developer, who adds comments as to the root cause, and often other possible symptoms. That way, ...


11

A label is just a label. It is far more important to understand what stands behind them, so people can easily say when to assign a certain severity to a bug and understand what such severity means in terms of business impact. This is important because depending on the severity* your stakeholders may take appropriate action. E.g. stop releasing the product ...


11

We prefer to talk to developers first. Then, we together decide if detected error is a result of some quirk in processing and not even worth of bug, or, if it is worth a bug, we negotiate who will enter it to Bugzilla (we call if "buggify the feedback"). Often, developers prefer to write the bug description, because that way they can better describe the ...


11

Do not discuss defects immediately with developers. Mainly because context switching is bad for their focus and could take up to 5-30 minutes to recover from. How to communicate a defect depends in which stage of development the defect is found. When I find a defects during testing of a task of the current iteration then I document the defect in the ...


11

I think, it is always good to discuss things in person. You are lucky you have that things going on at your work place. In many companies all communication happens only via a system and that at times creates lot of confusion. What you write and what the other person understands may be completely different. For things like developers don't consider the bugs, ...


10

Log the bug. Firstly, it's often turns out to be useful to have a record of the bug. If the bug manifests itself on a customer's machine at some later point (perhaps months later) and it suddenly becomes important to fix it, at least you've got somewhere to start from. Even if the developer cannot reproduce the bug, they may be able to add extra logging ...


10

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


9

Here's a couple things that I look for in a bug report. Exact steps to reproduce. You might be able to get away with some slang, for example in our APP you can almost always press F1 to move to the next screen, so you might see someone say "F1 through until <>". But you can't just say "Go to this function, this order number". Unless it has a problem ...


9

I document the following: What I think the problem is. Sometimes this can be tricky, and if I'm not certain, I'll talk to someone about the functionality before submitting it. What do I think the expected result should be? Again, tricky. See #1. Steps to reproduce. The easiest way to a developers heart is to provide detailed easy to follow instructions on ...


9

As a tester on a small team in a large organization, my answer may be skewed from that of a tester in another situation. I'm all fine for testers fixing bugs, but, we also need to realize that we specialize in testing, and developers specialize in coding. We could fix it, and it could break something else that we don't know about. At the end of the day ...


9

There are at least two (conflicting) ways to think about this: Whether you provide a default depends on the context. If you provide a default, you should be prepared for people to select it even when it's the wrong selection. This is particularly true for user interfaces that require lots of inputs. For example, my company's application has an online ...


8

I don't think fairness is the issue. More important: Would a report be useful? For the web service usage, the usefulness of your report depends partly on the scope of your review. Given the code you reviewed, you have a concern. But perhaps other code (outside the scope of your review) prevents the problematic scenarios you're concerned about. ...


8

Yes, it is fair to report bugs, no matter how you have detected them. You may find that the developers need the steps to reproduce the problem, in which case you may have to do more work before you can expect the bug to be fixed. A bug found by reading the code is still a bug. (Unless it's not actually a bug because you misread the code, or didn't ...


8

I tend to prefer allowing anyone in any capacity to log defects on any team I am a part of. It helps build a sense of ownership of quality in the entire team, which is as it should be, every team member regardless of role should equally own and care about quality. It is a different story when people outside of the project team are entering defects, I would ...


8

Without being flippant, this sounds like you've got a serious communication problem in the team. Given the limited timeframe, here's a few things to consider: everyone in the team needs to know what a good bug report looks like everyone in the team needs to search for a bug report on the issue they're seeing before they write up a bug report. This means ...


8

It's not necessary for QA to do root-cause analysis for every defect they found. It's up to circumstances. And for the level of drill-down, I did not drill to the level of source-code when I tested a Unix binary application. But I did html/css root-cause analysis when I tested a website. As a view of user I represent, I access only the information that a ...


7

There are a couple of senses in which developers ask testers to reduce a bug. First, it's often handy to be told which values of which inputs trigger the bug. And second, sometimes the tester tries to narrow down where in the product the bug arises. I assume you are asking about the first. Rather than asking for generally-applicable checklists, perhaps a ...


7

If they have the knowledge to fix in, why not ? I can see where the bug should still be reported for those places that want traceability etc and presumably the tester will first write a failing test to demonstrate the bug...



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