Tag Info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 consicse as possible Reproduction steps. You should be able to reproduce the bug and hopefully have narrowed it down to the simplest possible steps. Evrionment considerations (OS, browser, ...

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

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

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

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

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

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

There are several possible outcomes: It's a QA process for you, not you're for the QA process. As @dzieciou noticed, if you think that solving the problem would be faster by just picking up the phone and speaking to the developer, it worth trying. In case if the developer says, oh yes, I'll do it at once - the problem is solved. However, the developer may ...

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

A bug report should include as many details as possible. But keep in mind that it should not bog down the tester from creating them if it involves lot of effort from their part. A good template should contain Title (Short and descriptive), Build No, Requirements Reference (Optional), Problem Description, Expected results, Steps to reproduce, Analysis ...

In my company, a good bug report: Describes the symptoms, including screenshots or stack traces if necessary Specifies exactly how to reproduce the problem Specifies why the author believes the bug is important, if it is not already clear Some developers may prefer that the tester attempt to narrow down the problem as much as possible. My developers ...

1.Short and meaningful title (which will give the exact problem statement) 2.Repro steps 3.What is the actual result 4.What is the expected result 5.If applicable screenshot/video to get the repro 6.What is the severity of the problem 7.What was the Testing env 8.What was the build no 9.What is the source (Test/PM/Dev/Design etc) of the ...

Why would you want to use a bug tracking system for tracking issues in a Request for Proposal? You could just do that via comments / editing features in the word program you use. You could use Google Docs to create a spreadsheet and put a link to that public document on your website for reporting RFP issues. Better yet you could create an RFP issues ...

Something like: http://dan.hersam.com/2009/05/01/how-to-display-keystrokes-for-screencasts-on-windows? also referenced on: http://superuser.com/questions/239403/what-software-is-available-for-showing-keystrokes-on-the-screen Just ran across this too: ...

You should certainly log the issue, probably with the word intermittent in the title and perhaps a keyword/tag specifically for these kinds of bugs (depending upon your defect tracker). In addition to the steps taken to recreate this bug, because so many of them depend on what you did before the particular operation that triggered the bug, try to capture as ...