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

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

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

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

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

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

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

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

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

It often happens that notification popups/balloons/components are reused across whole application. Hence, a defect you have found may appear in other part of the application. I would try to confirm that first (e.g., by checking other pages and talking to your developers how components are used), and if so then the issue may need a separate defect. However, ...

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

In actuality, the usability issues only come into play in a very specific case. In most cases, providing a default for a radio button list is actually a straightforward logic issue. Here are all of the parameters I can think of (in order of precedence): Is the user required to provide a choice? If no, then a default selection should never be ...

What does "acceptance test was met" imply in your shop? In some shops "acceptance" means the owner/end user/relevant stakeholder has deemed the software sufficient (not perfect, but good enough). Further, in some shops this implies that no further funding is authorized for the project. If this is the case in your shop, then your only option may be to ...

In my company some teams report problems found in code review using collaborative code review tools like Crucible. Those allow to share comments about the code inline and integrate easily with IDE. Our architect sometimes send e-mails with code review results and they go through grooming and are included in the backlog of stories to do. I, as a tester, try ...

Sounds like a hosted solution would best meet your needs. Is that something your company's security policies will permit? And will you have time to gain permission to share bug reports externally? Another alternative is to use your internal bug tracking system, but appoint someone to handle bugs found externally. Your third-party dev team sends bug reports ...

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

Sometimes you will find non-technical project managers and to make the matters worse they work against metrics rather than common sense. However, his question is legitimate to some extent. Given a feature, you could always come up with N number of tests (after applying equivalence class partitioning, pairwise etc) and then you can group them as functional ...