On Fri, 02 Sep 2005 19:56:49 GMT, "Oliver Wong" <>
wrote or quoted :
>
> Assuming these non-engineers are employees of your shop, it doesn't seem
>unreasonable to spend an hour or two as a "training" session to explain how
>to fill out the bug report form on Bugzilla. Regardless of what software
>you'll use, you'd probably get optimal use out of it if you do spend a few
>hours training the non-engineers: they might not know how to write effective
>bug reports! Make sure they're aware of the 3 basic pieces of information
>that make a bug report useful:
I wonder if it might pay developers to have a log feature to help in
tracking bugs. It would take a snapshot of the registry and data files
and bundle them up in a zip, then log keystrokes and mouse clicks and
moves (possibly abbreviating moves). Then the vendor would have an a
way of knowing exactly what the user did and where he started from.
Maybe there might be a way to get a screen snap even after the app has
crashed.
In the old days of DOS/Abundance I did a screen snap, stack trace,
crucial application info -- e.g. what variable it was working on in
what array in what file and error message to printer (or virtual
printer) so that they would have something concrete to send me without
any work on their part to copy. Now we have high speed Internet, we
should be exploiting that rather than relying on users to tell us what
happened.
The other tool I have not seen used is something like PCAnywhere where
the vendor and customer watch simultaneously as the customer causes
the problem.
I have found vendors much more willing to take action if accompanied
by a screen shot. That is much more compelling proof there is a
problem than any number of words.
This brings up one of my pet peeves, error message filled with hex and
other gibberish you cannot copy/paste to give to the vendor. Copying
this to paper and transcribing is time consuming and introduces
errors.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.