Bug tracking methodology

I'm working on software for a company that doesn't ever file bug reports, the only complain, "so and so isn't working." Sometimes I can figure out what they're talking about, sometimes not. My pleas for screenshots and more details fall on deaf ears (once they did take a screenshot, then printed it out, scanned in it with their fax machine and emailed it to my boss as a TIFF).

I have several methods inplace to give me the data I need. Here are the steps I've taken:

• A bug tracker in which they can enter bugs (only one was ever entered)
• Error logging. Every time an error occurs, it writes it to a log file, courtesy of NLog
• Program has a try catch around it's initial method to record exceptions.
• When an unexpected exception is caught I take a screenshot of the program.
• Access to all forms are logged, and to some extent, what they're doing. (although this usually only works if they succeed)

What other methods can 开发者_StackOverflow社区I employ to allow me to catch bugs, and gather more data about them so I know how to reproduce them?

To be fair, it sounds like you're definitely doing your part of the job well enough, you've implemented the software, you're active logging the errors, you're nearly out of options.

I'd schedule a formal meeting where you discuss the importance of bug tracking - why this needs to be implemented, and why the current system is failing. Explain to them how this is slowing your job down - meaning money is lost.

Educate them and they will follow. Instead of being "that annoying developer who wants us to spend hours on some random piece of software", you'll be "that developer who is actively coming up with new solutions to problems and issues found, and making the right steps to rectify such situations".

In reply to your comment saying you're "only an intern" - this should be irrelevant. You're just as entitled to explain your opinion, especially if it's going to save yours as well as other people's time, money and effort. Speak to a superior, get them to schedule a meeting, it'll show initiative, care and prosperity - three major factors that they should be appreciative of.

If you have bug-tracking software, use it. Even if you're just entering the information your users tell you, it's a start. Tell them that bugs cannot be fixed without details of how to reproduce. Also, all your colleagues and testers should be using the bug-tracking software themselves.

Use a "supervisor" which monitors the application and records contextual information about it e.g. amount of memory it uses, amount of memory available in the host, number of open files etc.

The sort of data that might be useful to know when the application crashes and (of course) didn't have time to log.

It sounds like you need to educate your client on how to appropriately communicate with you on issues or requests found. I recently requested that one of our clients purchase SnagIt. It's a tool that makes taking, annotating, and emailing screenshots a breeze.

https://store.techsmith.com/order/snagit.asp

Be patient, and work with them (individually) to improve communications.

They are customers, not part of your company. There's a saying "the customer is always right". As customers, they may feel that you are asking too much for them to use your bug tracking methodology and tools to make life easier for you.

But a bigger question is -- does your software have too many bugs? Part of their dissatisfaction may be with the quality of the software! Your mention about just now putting in try-catch loops seems to indicate this.

Improving software quality.

1. Do you have a test environment, separate from your dev environment, where you thoroughly test all software, scenarios, unit tests, automated testing, manual testing, before delivering to the customer?

2. Do you have testers whose sole purpose is to test the software?

3. Do you have documented set of tests and test plans for the testers?

4. Do you have automated unit tests for all your codde?

5. Do you have coding conventions and standards, requirements/design conventions and standards, test/test plan conventions and standards, a process for the SDLC, root cause analysis?

6. Do you have peer reviews?

7. Do you have checks to ensure that all issues from peer reviews are addressed before moving to a test/production environment?

All these things might reduce the number of software defects, and make the customer happier, which is really the main goal.

Now, about your original question.

Clearly they don't like using bug tracking software. So, you have to be pro-active and follow the suggestions of the previous posters. It sounds like this is exactly what you are doing, and you have taken some good steps to do this. You're on the right track!

1. Improve your logging so that you can gain information after the fact. You're doing this.

2. You should also have remote access if possible so that if they can duplicate the bug you can see what is going on.

3. If they send information about a bug to a point-of-contact in your company, that person has to ensure (either by doing it themselves or subordinating to a delegate (My guess is your boss is the point of contact and you are the delegate :)) that the bug is entered with all the relevant information.

4. Ideally you could havea mode where you capture user interations and can reproduce the bug via playback feature.

5. You could install a video cam and record what they are doing, so if they call in about a bug and are able to reproduce it you can see exactly what they are doig.

I had a similar problem a few years ago at my work place. Basically it all boils down to company policies. Once you know you found the right tools, like the right bug tracker software (we use Redmine, by the way), you have to enforce their usage.

At my workplace I had to talk to my boss about it, explained every important detail about the tools, demonstrated how they worked on test servers, and pointed out how it can save time, nerves and reduce costs.

Afterwards we had a big meeting, a lengthy discussion with everyone involved (especially the testers), then decided how and when to use the selected tools. Now one of our policies is: If it's not in the bug tracker and reasonably documented --- most importantly reproducable, it's not a bug and won't get fixed.

It took everyone some time to get used to the new workflow, but now nobody wants to miss eMail notifications about bugs, nightly builds and our daily "coffee round" where we have some chit chat about what is coming up and what priorities changed.

Hope that helps.

Put a button on each form / page of the application itself. It should be prominently displayed somewhere. When they click the button, have them fill out a textbox saying what the problem is.

Don't have them prioritize or categorize the bug. It should simply allow them to type whatever they want into the one field. Your app should collect all the information you think is necessary and submit that to your bug tracking system. Once there you do the rest..

There are various ways you can monitor your app crashings (.Net Specific) Windows and Web Applications 1. In its Global.asax.cs file, under Application_Error method write log to a text file so that you can all sorts exceptions with their stack trace and all things. 2. In common scenario other than .net Environment, you can build a common method so that it can be called to write log whenever you have exception, means in every try - catch or if there is any platform for such is provided.

Or if you dont want to write log, and is working under windows environment then u can go to event viewer and filter out your applications crashes with its dumps.

Also Nlog is a good way to log.

For filing and fixing bugs , you can use Trac for tracking and fixing issues so that one should not need to take printouts / faxes. Everything online , free and fast.

Hope it will help

Follow this for exception logging

1. Form/Page on which error occurred
2. Event/method
3. date/time
4. Its Stack Trace
5. Error Message
6. Some Error Code
7. User
8. Line Number if possible

I'd go one step further from DisgruntledGoat's answer, and say that anyone in the company who is in contact with the customer should be knowledgeable about the bug tracking tool, and should enter problems as reported by the users­. This means sales reps, project managers, customer support, etc...

These are the people who have a lot to gain from having happier customers. At first, you might need to do some hand holding. But when they realize that the best reported problems get solved faster and help them bring more sales/less work, you'll see the quality of bug reports increase.

We've used rt for user bug reporting, I mean reporting by users of the bugs they find, not reporting of bugs in users, of course. The neat thing about rt is that it can be presented to users simply as an email address. The instructions are about as simple as can be: find a bug, send an email. In my experience this is a much simpler sell than Trac, Bugzilla and all the rest. They're good in their various ways, but they all look, to most users, a lot like computery form-filling.