Immediately bounce the ticket back to the developer, with a 'no evidence' type comment, expect them to do the same with poorly documented defects and everybody wins.

To elaborate, don't just expect them to do the same, encourage it. The objective of both programmers and testers is to meet the requirements. Neither are paid to just code and test. Coding and testing are the how you meet the objective. If not present, an esprit de corps needs to be cultivated. The old school approach pitching testers in competition with developers is counter productive.

IOW, you already have the code. You have the ticket, which should have all of the relevant information that you gave the developer to fix. The ticket shows the observed behavior, steps to reproduce, and expected behavior. What more do you need? What more exists? What extra information is there? If you have all of the rationale behind the code change, and all the code that has been changed, what value is there in having an explanation of the code change? Either you can read the code and figure out the 'why' yourself or the 'why' doesn't matter to you, no? What am I missing?

@Shane sure, here is something recent we had. So, in a specific part/screen of our application, there was an intermittent problem with a disappearing horizontal scroll which was happening every now and then several releases in a row - we had some theories and finally found a relatively reliable way to reproduce the problem. We've documented our observations and sent to a developer asking what he thinks. Then, it's just "fixed, please test" coming out back. I mean, okay, but clearly in this situation we all expected more..thanks, good questions.

Are you located in the same place?

@KevinMcKenzie nope, it's almost entirely remote. Thanks.

You expected more, ok. But what exactly DID you expect? You want 'developers to be as detailed as possible about what caused a problem'? Ok, that's the steps to reproduce. You about as detailed as you can get about what is causing a problem. You also want 'developers to be as detailed as possible about how they fixed it'. That's the code. Literally cannot get more detailed than that. So what are you looking for? I'm only hammering away on this point because I'm betting the dev is having just as much difficulty understanding your request as I am.

tl;dr Without knowing what you actually want to see, it is hard to give it to you. "More details" isn't specific enough for the dev, from his perspective, it already seems like he's giving you as many details as possible. "More details" also isn't specific enough for us give a great answer, imo. My advice? Go back through his recent fixes and write what you would have expected to see. At least that way, he'll have a good example of what you want. I think I might want to convert this into an answer...

@Shane there is problem with your assumptions: some of our testers cannot read code (AngularJS/JS specific in our case). Then, the commit messages they use are not descriptive - there are only ticket numbers there. And, steps to reproduce does not always relate to what the actual problem was. In other words, we do have this "not enough information" situation. Yes, it might/should be solved on other levels - like descriptive commit messages or going over the problem and the fix with a developer in a separate session.. I though believe, just a couple extra notes about the fix would only help.

@Shane for example, for that problem I've noted above it could be "This bug was caused by this opened Chrome issue that effects the table elements when a browser window is resized. I've applied a workaround suggested here.". This provides valuable information for testers especially in case of intermittent bugs or problems that have an unclear cause. Hope you can see my point. Thanks.

You could always start rejecting their builds with the bug report "This is broken, please fix."

@Shane "steps to reproduce" ≠ "cause of problem". The cause might be something like "referenced constant instead of variable" or "started loop at index 1 instead of 0".

@DanHenderson Those aren't the causes. Those are the actual fixes.

"This bug was caused by this opened Chrome issue that effects the table elements when a browser window is resized. I've applied a workaround suggested here" If the developer did write that they would be repeating information. All of that is info that QA should be giving to the developer. Steps: 1) Use Chrome 2) Resize window 3) observe how table elements are behaving. If the QA department is asking the devs for this type of information, there is a problem in QA.

Moreover, workarounds HAVE TO be commented in the code. "Workaround for bug in Chrome v3.1.2. Open issue at chromeissue.com/1234" If a dev put in a hack without leaving a comment in the code, I'd be furious with them. If QA asked a dev to repeat all of their code comments, that violates DRY and I'd be pretty pissed with QA. Again, what information does the developer have in his head that you want him to write down that isn't already somewhere else?

@Shane Well, no, for example with the cause I listed of "referenced constant instead of variable" that would be where the variable is what should have been referenced, so the fix would be "adjusted foo to reference variable". Likewise with my example cause of "started loop at index 1 instead of 0" I meant that in that hypothetical, 0 was the correct index to start at, so the fix would be "modified loop to start at index 0". But my point was that if the bug is "this link turns pink when I mouse over it" then the cause is not "mouse over this link", it's "wrong color set in hover style".

...And then the fix would be e.g. "changed hover style color from #ff00ff to #ff0000"

Joined SQA to weigh in here. As a developer, I lean far closer to what @Shane is saying. Sometimes, a dev could write pages of text and it would not be enough to explain to someone who can't read the code. It is hard to add "more details" without knowing the level of what is desired. How much time should they spend on it? How high-level should it be, etc. It seems your intent is to have enough knowledge to look for patterns, and that is a good thing. Most likely you will have to be able to dive into the code to get that in any meaningful way. However, it can be .... continued....

... continued ... very useful for the dev to tag patterns as they are found. This allows focus and analysis to be placed on tricky or continually popping-up issues. Think long and hard about some categories and maybe work with them to tag any applicable issue with a category. Just bear in mind that not all issues fit neatly into one specific category.

How exactly did you convey to the developers the added benefit of supplying this extra information? Did they agree with you that it would be worth the effort? Please be as detailed as possible.

How does "I now check for null and return" or "I added a catch for that particular exception" help you do QA? I can understand "I now handle the issue properly and show a message instead of crashing, " but that's what, not how.

@Andy If the tester knows the bug fix was adding a null check, they can look for similar bugs by trying to pass null in other places. Uncaught exception? Try generating other types of exceptions.