Question: I sometimes come across bugs that do not have enough information to reproduce the bug, or worse, understand what the issue is in the first place. Usually, business analysts, rookie QAs & sometimes developers write nonsensical bugs like this. **Contrived** (for simplicity) examples - 

**Ex.1** I see a server error when I open this webpage, for this user. The username and password is xyz.

**Me:** Does the page give more info about the server error ? Did you check the network inspector of your browser ?

**Ex.2** I open the ecommerce webpage & add items item1 & item2 to shopping cart. Then, I see that the underlying CartService's api call getCartTotal response has Item 1 discount=0%. This is wrong. In ItemPriceService call getItemPrice(theItem) we have Item 1 = {$50, discount 10%} & Item 2 = {$100, discount = 0%}.

**Me :** So, you meant to say that in the shopping cart, any discounted item is priced at its regular full price. (...and the rest of the info in your bug report is the underlying details of the bug)

Due to such bugs, I often have to waste time in chatting with the bug reporters to understand & reproduce such bugs. How do I deal with such poorly documented bugs ?

**Some solutions I think might help.** Do you see any issues in these 
solutions ?

* Save 2-3 poorly documented bugs somewhere & make current employees & new candidates try to figure out what the basic issue is & how to reproduce it. Then, show them the well documented version of the bugs to understand how much pain others go through in understanding the bugs. I will have to ask management to do implement this solution.
* Create general guidelines for bug reporting, perhaps even specific guidelines for api testing, UI, database etc.
* Reject the bug saying that its not clear what the issue is.

Answer: 
This is company specific. Any sort of bug reporting can work in different teams.

Your two examples seem kind of silly though. Whats so unclear about opening and navigating to web page, and reproducing error, or adding items to cart and checking what discounts are applied?

My personal opinion is that when dealing with new or inexperienced developers, one needs detailed bug descriptions, 'press x, then y, then z, got this, expected that' while when dealing with more senior ones who take bugs seriously 'shit doesn't work yo' is sufficient. Some even LIKE to chat about bugs.

If you don't understand how to reproduce the problem at all, just reject, reject. Reporter will get a hint after a few times.

Quite often testers don't have time too, to investigate every bug in detail, so they notice problem, quickly report and are off to find more problems.

If its a TEAM problem, bring it up in any of regular meetings, see if anyone agrees with you, bring examples and brainstorm a solution. Maybe you need more detailed steps, or more information than 'press X there is an error', and that's fine.

If it's a YOU problem, then reject what you don't understand, bring it up, but be prepared to adjust that there will be no resolution.
Team effort should do the trick.

For each project you should have a test strategy, you should also have a guideline with how a bug is reported and the flow that a bug has.

Reporting a bug is an important activity, a poorly written one can result in a lot of time spent digging in the wrong places.

Each bug need to contain details enough to reproduce it and to have a clear description.

What thing you can do to improve this:

* talk with the person that reported the bug and ask nicely for more details
* if no guidelines for adding a bug is documented and you think is needed then ask nicely in a meeting for this
* if this happens often then you should talk with the QA lead from the project, else the Project Manager, this should be handled by the team
* make use of meetings like `scrum` and `retrospectives` and others to see what anyone can do better to increase the value and the efficiency of the team
* try to solve this issue in such a way to make a better team
* make small gesture if the bug is updated with better info, like say thank you once in a meeting to that person for the effort of writing better description for bugs, leave a sticky thank you note on the laptop, sometimes small gesture can do much

Things you should NOT do:

* talk directly with a person that has 2-3 level above, like QA manager, remember you are a professional and a team player and should solve this inside the team
* simply reject the bug if you do not understand it without trying to improve the communication in the team
* showing the bug in a meeting and ask tell how to reproduce it or explain it