Tag Info

Hot answers tagged

27

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


21

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


11

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


10

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


10

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


9

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.


9

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.


9

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


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

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


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


8

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


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


7

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


7

No, they shouldn't. The major reason is that the natural role of Developer is to stand up for idea that "the program is working". The natural role of QA is a direct opposite: to prove that "the program is not working". If the same physical person acts for two opposite roles, this may lead to compromises with themselves. Specifically speaking, sooner or ...


6

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


6

The ratings that I see in common use and have used historically are: Severity 1 - Critical issue, crash or data loss Severity 2 - Major issue, but no crash or data loss and no workaround Severity 3 - Issue, with no crash or data loss and a workaround exists. Severity 4 - Fit an finish issues. The main decision that needs to occur for each bug is "Are we ...


6

There seem to be a wide range of answers from "Yes, this makes sense." to "No, don't you dare." I can see both sides of the question so here's an answer in the middle. It depends. It depends on the role of QA on a particular project. If QA has been involved in the software development lifecycle, if QA has played a role in defining requirements from ...


6

First, I would like to say that often just taking care of exception is enough. Maybe it's a forgotten corner case (sort a list, but forget it might be empty). Of course you know better when you can trust the developers to make sure that fix is correct. Then to your questions: It would be really nice to have the steps in each bug. It would be even better ...


6

The first thing you want to do here is perform some bug triage. Problems your team finds during feature testing will be one of: something introduced by the changes something that was there before and doesn't have much if any impact on the changes something that was there before and has a major negative impact on the changes The developers in the team ...


6

First, it is absolutely professional to ask for more information when you've made a number of attempts to reproduce the problem and haven't been able to do so. You've effectively eliminated the most obvious potential problems with your attempts to reproduce, so the cause is something less obvious: it could be the customer using a different configuration, it ...


5

Couple of guidelines in addition to above listed items Test Steps Snapshots for each steps if possible (In case you are working in remote teams, to avoid to-and-fro email communications) Expected result vs Actual Result Environment Details - OS, Hardware, Software, Build version Log file entries / values Nice to have - Preliminary investigation / analysis ...


5

A clear title - I want to be able to be able to tell at a glance without going into the report itselt what I am looking at. Description of the bug - this should be as concise as possible. Reproduction steps. You should be able to reproduce the bug and hopefully have narrowed it down to the simplest possible steps. Environment considerations (OS, browser, ...


5

There is no one "right" answer. The number and type of categories of defects that would be appropriate to your context depend upon several factors, including: Type of application Your team size The level and frequency of "in the hallways" conversations between people on the team The number of bugs you have "hanging around" waiting to be taken care of etc. ...


5

I think you should ask the developers and business owners rather than us. :-) Ask them how to handle these kind of border cases. Do they want bug reports also on unclear things to remind them or do they want to talk about them first and decide case by case whether to file a bug? Remember it's your task to provide them information on what is or could be ...


5

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