Hot answers tagged

48

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


20

It is always a very good practice to start testing as early as possible. By not fully implemented if you mean still under development, then I suppose that is not such a great idea. Yes, you can go for incremental build releases for testing, that might be helpful. When you say that your testers all log the same bugs, well there's your problem! Do you ...


17

I think the problem arrives from how you use your VCS: You want to commit your code because you have finished a sub task and want to have it backed up in case of e.g. a hdd crash on your workstation. Your testers see changes in the repo or get an automated build which they test. One solution could be a separate working branch which is work in progress. No ...


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


14

To me this is a perfect example of what happens when effectiveness of testers is assessed based on the wrong KPI, in this case, a number of bugs reported. In the end it will harm testers, developers, relationships between tester and developers and as a result product quality. To me this is wrong KPI and there is been at least two discussions here why is so: ...


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


7

Because there are no requirements, I would say go with your first option. You are relying on normal expectations based on the button text. If the bug is rejected, you can ask why. Better yet though, find someone who should know (PM/BA/Customer or maybe even the dev) and find out what it's supposed to do. The more information you have, the better bug ...


7

I think your suggestions are very good, it is always good to have clear guidelines. Though they should not be set in stone and should be used as a guideline and not as a rule. Full-screen In order to reproduce the issue I want as much information as possible. A screenshot can tell a thousand words. Some people make only a screenshot of the part they think ...


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


6

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

Most of the companies I've worked for over the last 10 years are using an Agile approach. In this approach there are several factors to pay attention to such as: favor direct communication over formal processes encourage a team approach sit together I find that in such environments you want to seek out practices such as: pairing on test plans before ...


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


5

It makes zero sense to waste time on testing a feature (and reporting bugs, and triaging them) if development is not finished yet. All this work will have to be redone again when code is finished. Something is strange in your process, if testers have so much time that they create extra work for themselves like that, which has no benefits to the project. Do ...


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

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

I will answer/go through your points one by one and will try to add some valuable information in addition to your useful & precised description. Color usage in images: Highlighting becomes critically important when creating bugs related to GUI. Regarding the color, we have been using Red (R =255, G=B=0) and Blue (R=G=0, B=255) color only for ...


4

Images for bug reports should: contain all the information needed. So for browser screenshots use the whole browser window so people can see the browser, browser version and any toolbars that reflect installed tools and any footer toolbars that show info. not contain irrelevant information. I am not a fan of the whole desktop screenshot as it includes ...


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


4

No, it doesn't make sense to test code that you know is incomplete and not ready for testing. But rather than blaming your QA folks... I suggest that you take a closer look at your software development process. It sounds like there is a failure of communication between developers and QA, and a mismatch of expectations. For instance, it sounds like you are ...


3

Timebox it and afterwards evaluate. I would say time-box one hour and then see how probable it is the tester will find the steps to reproduce the issue. Often its easier for developers to reproduce the issue, since they understand the code for that part. And they are more proficient in code-debuging.


3

Possible issues with using spreadsheets are that: you are dependent on an external company for software for access to your historic tickets. the only workflows are manual - no enforcement you will eventually run out of space or the sheet will get too big to handle difficult to add attachments such as screenshots of the problem, etc. I would suggest ...


3

Working with spreadsheets is not bad and strange, it all depends upon the scope and type of tracking you want to do, if you have a limited scope of test cases, issues and requirements, then you can stick to the excel sheets but in long run you will need some tracker which will make your work a lot easier and will itself perform some of your tasks which do in ...


3

If my dev counterpart is available I try to talk with them first. That gives them the chance to request extra information that I might not have thought of. If my dev counterpart tells me that that area is not ready for testing, I tell them I will enter a bug just to remind myself to come back and look at the area once they believe it is ready. If I hear ...


3

The fact that multiple testers test the same thing without even talking to each other shows very clearly that the process is broken. You shouldn't have 2 developers develop the same feature independently and you shouldn't have 2 testers test the same feature independently . It sounds obvious, but if 2 people work on the same thing, they need to know about ...



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