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.
Poorly documented bugs should always be countered by defining a mandatory template for logging bugs.

**Summary**: Define the bug in 140-200 characters. Usually it should be in the following format;
When you can't perform an action:

`Unable to perform [some action] on [some module/page/component]`

When there is incorrectness or mismatch:

`Mismatch in [message/filename] when [trigger action]`

**Steps to reproduce**: I recommend using Gherkin language to define steps.

Format:

```

Given a precondition
When actor performs some action
Then expected results

```

Example:

```

Given User has forgotten password (PASS)
When User clicks on 'Forgot password' link on login page (PASS)
Then Application is redirected to 'Reset password' page (FAIL)

```

**Expected behavior**: Usually the expected results as precise as possible.

For example;

```

The correct warning message to be displayed is #E4054: "Please enter valid credentials."

```

**Actual behavior**: Usually the actual results; as precise as possible.

For example;

```

The warning message displayed is: "EXCEPTION WHILE LOGGING IN! java.lang.AssertionError"

```

**Build/Changelist Number**: The build number or changelist or version of the software being tested in which the bug was found.

**Environment** The environment in which the bug was found. Can be Test/Development/Staging/Production, etc.

**Attachments**: Screenshot / video of the steps to reproduce. Logs that are generated in case there are no screenshots. Any other files to support the existence of bug.