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


19

I work as a Manual tester on a big project. My project follows Agile methodology. I test a Web-based application. I sometimes ask my self , that am i giving any value to the stakeholders? So, the value that you are giving to stakeholders is the reduction in the amount of defects that go to production. The cost of fixing a defect drastically increases over ...


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


13

You've got a pretty good grasp of the defect life cycle, however the terminology and even the flow can change from project to project and team to team. Most likely, "Open" is the same as "New". More important than what term to use is ensuring that the team are all using the same terms.


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


9

In our organization, there's one defect (2nd one opened is a duplicate), but there are two test cases which fail.


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

As others have said, it depends. My usual method works like this: I find something that doesn't seem right: If it's really obvious (a typo in a high-profile part of a site, an error message that gives the line of code that's failed), I'll check with a developer to see if they're working on that code right now (this is often the case in agile or other ...


7

I imagine this would depend on the bug being raised. If it's a glaringly obvious bug (pages not loading, basic function not working, etc.) then I wouldn't waste a developer's time confirming it and do a write-up. However if I come across something that may be considered an edge case or I'm unsure of the intended functionality (mostly found during negative ...


7

Should Testers first discuss the bug with the developers before reporting it? From my experience in several different organizations I think the answer given the current question details is "it depends" It will depend on general factors such as: size of company size of development group current deadlines location of developers industry development ...


7

As a corollary to what David said, testers have the same memory limitations that developers do. If you don't log the bug, chances are very good it won't get fixed. This is especially true if it's not a severe bug, as chances are very good that the developer(s) are working on fixing severe problems first, and won't fix less severe ones for a while. And by ...


6

Unless you are certain that the root cause is identical and fixing one will always fix the other, I would make it two defects. The developers can mark one as a duplicate later if that turns out to be the case. What you don't want is to consider it a duplicate, the developers fix one thing, then the other error turns out to have a different cause or another ...


5

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


5

Many shops would have an additional outcome to your step 2. Now the defect will be evaluated by dev team manager: i.If the defect is not valid then STATUS = Rejected ii.If defect is out of scope then STATUS = Deferred iii. If defect is a duplicate then STATUS = Duplicate iv. If the defect is none of these, then STATUS = Open (Some shops mark a defect ...


5

Tester is just a label on an employee. Testing provides value. It is virtually impossible to write bug-free software, and so software that has not been tested is virtually guaranteed to be buggy. Someone needs to test it. Who tests depends on the circumstances. Some people are good at testing, and some are not. You probably want the person who tests to ...


5

It depends... What is the overhead associated with reporting a problem? Some organization have big enterprisy processes, that requires lots of clicking, mandatory fields and multiple actors between the time a problem is open and the time everyone is done with it. You might also loose sight of important problems if they're drowning in a sea of minor (or ...


4

Yes, Selenium is an active project (see commit history on GitHub). Then why are there so many unresolved open issues? It's open source. We can't expect the team members to fix bugs on a daily basis, because they are just enthusiasts and all have real-life jobs. The developer in charge of a particular area may not have time to deal with it right away, even ...


4

If there is possibility to discuss the bug, it could be valuable, for example you will have direct information of the cause and who will be the assignee of the bug. But generally it is not mandatory. It could be done as well after the bug is reported. Does not matter if you discuss the bug with developer or not, probably you will have to report the bug ...


4

If the tester thinks that it is a defect, most likely it is a defect. The developer may be correct that the process is working as intended, in that case the defect is possibly in the documentation, user interface or testing plan. It should be logged, even if is testing error. This will lead to better determining where documentation deficiencies exist.


4

Definitely make a ticket. If the bug is "don't fix", you can refer another tester or developer who finds the same bug to the existing one, and save the developer some time. If the bug is a quick 5 minute fix, it still takes 5 minutes to do, and you have to remember to properly re-test. If these little distractions add up and are not documented, things ...


4

If it is a clear and obvious breach against uncomplicated acceptance criteria, then report bug as soon as possible. Feel free to bypass the developer, BA or product owner. Otherwise, do not report the bug unless you first talk to the author of acceptance criteria (eg: BA or product owner), and the developer. If you do not: it is possible that you will ...


4

My view as a developer is that even if you are unsure it is a bug then report it. The upshot of this is (some of this has been mentioned by others) If you are unsure if it is a bug then you do not have enough product knowledge to perform the testing. This could be for several reasons, including partial training, poor documentation and insufficiently ...


4

It depends. Some of the factors I've found impact whether or not I report something formally or not: Development Methodology - If I'm working in an agile environment I'm more likely to work informally with the developer at first. In a waterfall environment, I'm more likely to report the issue because the developer has probably moved on to something else, ...


3

Determining who introduced a bug is without analyzing the code is: Extremely time-consuming if you want to install previous versions of software, you need to also accordingly change data structures, or have a copy of your databases for every database change keep switching between different versions which might have different behavior and you still have ...


3

Answers above are correct, let me make just a small re-phrasing of above answers. Depending on a bug/issue tracker software, there are several attributes of Issue. Status and Openness may be combined or separated. The common reason for having Openness separated is the consideration that an issue should be closed by the same user who has opened it. I ...


3

I would focus on the specific integration features that you need, and then come up with specific reasons as to why this info is useful and how will it increase productivity or reduce costs. Personally I find that many integration features to be bells and whistles. I know this doesn't exactly answer your question but I felt it important highlight. You ...


3

In my company there were around 63 integrations methods I needed wanted - I'll write down some important ones here: Support Request to Feature Email to Bug/Feature/Enhancement Commit(s) to Code Review Feature Request to Requirement Forum Thread to Feature Request There are many of them - but you gotta begin with whats most important for your organization....


3

Phil is right with how customizable it is. After a quick search, I found a couple of export/import plugins. A more important question may be however, why are the testers using a separate instance from the developers? Doing a constant export/import is just going to create additional overhead. It's all fine and well if you update once, but, wouldn't the ...



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