How can I persuade my designer to give good bug reports?

Question

So we have a small team for a certain project. Developer (Python), designer (html/css/jinja2), content manager.

Now, often the designer (html/css/jinja2) (who is quite technically adept in a Windows way) will pick up bugs and report them:

"Ali, I have a problem with text."

Should say "Ali, I am having an exception rendering unicode characters"

Or another example:

"Ali, I have the error page."

Should say what the exception is, when it's happening, etc.

Is there any way I can teach him? Note that he is technically adept, a good designer, and does understand the concepts. He just refuses as a first line to express the useful information without painful cross-examination. I am wasting about 7 minutes per report.

Answer 1

Ask him how he expects you to be able to fix the error if he does not explain it. Admittedly the unicode might be a bit tricky for a non programmer, but try to get across that the more specific he is in his initial report the less will you bug him about info later. That will save both his and your time in the long run.

Answer 2

In your bug tracker (you are using one, right?) mark the bug as "REJECTED: not enough information". He'll get the idea fairly quickly.

Answer 3

If he is not verbose, tell him to send you some PrintScreen from the buggy page. With that, you can actually see what's the problem

Answer 4

In your bug reporting script, you need to ask questions to dig deeper, e.g.

1. What did you expect to see?
2. What did you actually see?
3. What steps are needed to reproduce this issue?

Answer 5

Tell him what you need. Then use tools that will ease his work like Fogbugz with the screenshot program.

Do not try to belittle him or accuse him of wasting your time or doing more harm than good. From his point of view he is doing you a favor by letting you know of the mistakes you have done. Depending on his personality you should be able to frame his bug reporting either as he is making a contribution and taking ownership in the project or as a competition where he get's to "beat" you by filing bugs that can be solved.

Answer 6

I'd try to get him to use some empathy so as to understand what it unusable from your side. If you give examples he can relate to (perhaps something like a hypothetical customer/boss saying "the text is in the wrong place, fix it") then he'll appreciate how any action is impossible without any more information.

If you can come up with examples that might fit into his workflow, then hopefully he'll understand why the lack of information makes your job impossible, and will provide the context you need in future.

Answer 7

Find the answer to this question: What's in it for him? People won't change unless that change is obviously advantageous to them.

From his point of view, you should know all about the problem because a) you wrote the code and b) he has seen the problem. Since he has no idea what you do (or how), he can't make the connection between "what I saw" and "what you know".

So to get what you want, you must tell him: "I can't address your reports unless they contain the information I need to reproduce the problem. Attach a screen shot, the URL, and tell me what you were doing.". This gives a clear and easy recipe what you usually need.

Answer 8

I suggest to let him work on the issue queue for some time; you could ask him to help you sort out bug reports and to assign them to correct trackers/categories/developers (including himself). He will soon understand what's a good report, granted!

Answer 9

I think Aaron Digulla touched on the simple truth: What is in it for the designer. Explain that every time he encounters a bug it's time out of his life too. As soon as he realizes the better the feedback he gives you, the faster the bug will no longer be in his life either.

Answer 10

Read (and get him to read) Joel's Painless Bug Tracking article ... hopefully this explains the how's and why's to him

Answer 11

The Association for Software Testing offers a free "Bug Advocacy" course to AST members. Membership is less than $100 per year. Jon Bach posted links to the course materials in a 2008 blog posting.

The course was created by Cem Kaner of the Florida Institute of Technology and James Bach of Satisfice. It is probably more intense than your designer is ready to take (must pass the free "Foundations" course before taking the "Bug Advocacy" course). The course materials are Creative Commons licensed (slides and videos) and might give you some material which you could use to improve bug reporting.

Answer 12

A good bug report contains two things:

1. A description of what the software does in a certain situation differ versus what it should be doing (from the user's point of view)
2. A description of how to produce such a situation

If your user doesn't state his expectation or how his expectation was not met, respond to his bug reports by asking simple, specific questions: "What did you expect?" "What did you observe?" "How is there a mismatch between what you expected?" "What can I do to reproduce the problem in order to study it by myself?"

I strongly believe in the idea that people don't like wasting time, be it their own time or their coworkers' (your) time. I bet that after a while of being asked the same sorts of questions over and over again, he'll eventually start answering those questions in the first bug report.

By the way, looking at how programmers and designers tend to think differently, I don't really think that seven minutes per bug report is that much time. Sure, there is potential for optimization, but I believe most is gained by asking the right questions.