Tag Info

Hot answers tagged

22

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


20

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


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


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

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


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

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

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


8

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


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

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


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


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

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


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

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


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

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

At my current workplace, we don't distinguish between different ways that bugs are discovered. If a developer expects the test team to test the bug fix, they log it. If they don't expect the test team to test it, they don't log it. They understand there actions have consequences, and so they make that decision carefully. We never penalize anyone for ...


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


4

From your explanation two things I can infer Code review shows parameters not handled / passed No time to test it My Questions I would challenge why you do not have time to test it. You can check for Free tools like SOAP UI which can help to test the methods directly without writing single line of code Secondly reporting an issue without actually ...


4

I have personally found that the more you can reduce the overhead of developers fixing bugs before the code hits the main source branch the better off you are. I generally use a rule that as soon as a bug will be seen by or could effect someone else then it must be logged. This allows testers and developers to pair together as part of a pre-checkin review ...


3

You need to meet your project manager half-way. Using an unrealistic metric does not help either of you, and you are right to be concerned about that. At the same time, you need to avoid describing your problem in so much detail that your project manager will not understand it. Given what you wrote, I think I would tell the project manager something like, ...


3

I want duplicates. Well I would rather have duplicates from different people than not have them raised at all. Process wise, I use a daily bug triage where we review all new bugs that have been raised to identify them as duplicates and close them out straight away. If the tester is a repeat offender, I would simply have a chat to teach them how to use ...


3

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



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