How to Report Bugs Effectively

Anyone who wrote a program for public use, has received at least one bad bug report. Messages that are not talked about anything ("It does not work"); messages that did not make sense, the messages that were not given sufficient information, the messages that were given incorrect information. 

Reports of problems that turn out user error, reports about problems that turn a defect in someone else’s program, reports of problems that turn network failures. 

Learn more about software testing services

There is reason to believe the work of technical support, which is disgusting to do, and the reason - bad error messages. However, not all error messages are repulsive: I support the free software when you do not earn a living and sometimes I get a wonderful, clear, informative posts.

In this essay I will attempt to articulate what makes a good error message. Ideally I would like to see everything in the world to read this essay before you tell anyone about the error. Of course, I would like to see everyone who reports an error to me, read it.

In short, the purpose of error messages - to allow the programmer to see ourselves as the program fails. You can either show it in person, or to give precise and detailed instructions on how to make the program broke down. If they can make it fail, they will try to gather additional information until yet know the cause. If they can not make it fail, they should ask you to collect this information.

In the error messages, try to clearly define what is the actual facts ("I was at the computer and this happened"), and that - assumptions ("I think the problem may be in this"). Lower the assumption, if you wish, but do not immerse the facts.

When you report an error, you do it because you want that the error was corrected. It makes no sense to blame the programmers, or knowingly assist them: this may be their fault and your problem and you can be angry at them, and you may be right that get angry at them, but will be fixed faster if you help them by providing all the information they need. Also remember that if the program is free, the author gives it to you out of kindness, so if too many people are too rough with him, he may cease to be good.

"This is not working"

Believe me - the programmers have some rudiments of intelligence: if the program actually does not work, they probably would have noticed it. And since they have not noticed, they should work. So, either you’re doing something wrong as they are, or your system is different from them. They need information; supply this information - this is the purpose of the error message. More information is almost always better than less.

Many programs, particularly free ones, publish lists of known bugs. If you can find a list of known bugs, it is worth to read it to see if the error you have just found a well-known or not. If it is already known, probably not worth it to report, but if you think you have more information than the error message in the list, you can still connect to the programmer. They will be easier to correct a mistake if you can give them information that they already have.

In this essay, many of the rules. None of them is not absolute. Different programmers prefer different ways of reporting errors. If the program comes with its own set of rules error messages, read them. If the rules that come with the program consistent with the rules in this essay, follow those that come with the program!

If you do not report an error, but just ask for help in using the program, you should tell us where you are looking for the answer to your question. ("I looked in chapter 4 and section 5.2, but could not find anything that would tell me if this is possible) This will allow the programmer to find out where people expect to find the answer, so he can make the documentation more user-friendly.

"Show me"

One of the best ways that you can report a bug - it’s demonstrate its programmers. Put them in front of your computer, run the program and show what is going wrong. Let them see how you turn the machine to see how running a program to see how you interact with it and see how that program is doing in response to your input.

They know the program inside out. They know which parts they trust and what parts might be defective. They intuitively know what to look for. By the time the program will do something obviously wrong, they can already notice something subtle wrong and this may give them a clue. They can understand everything that the computer does during the test automation services run, and they can draw from this are important to them part.

This may not be enough. They may decide they need more information and ask you to show them the same thing again. They may ask you to tell the startup procedures so that they can reproduce it for yourself as many times as they want. They may try to change the procedure several times to see whether the problem occurs in only one case of a family of related cases. If you’re unlucky, they may need to spend a couple of hours with a set of developer tools and start to really understand. But most importantly - to make the programmer looked at the computer when it works properly. When they see taking place before their eyes a mistake, they will be able to take it and try to fix it.

"Show me how to show yourself"

This is the era of the Internet. This is the era of global communication. This is the era in which I can send the program to someone in Russia at the touch of a button, and he can send me comments as easy. But if he has a problem with my program, he can not do it so I stood in front of his computer when it crashes. "Show me" well, when it can be done, but often this is impossible.

If you need to report bugs to programmers who can not attend personally, the purpose of exercise - to enable them to reproduce the problem. You want the programmer has launched its own copy of the program, did the same thing and broke it the same way. When they see as there is in front of them, they can deal with it.

Thus, tell them exactly what you’re doing. If this is a graphical program, tell me what buttons and in what order you pressed. If you run a program by typing the command, show them precisely what command you typed. Wherever possible, provide a verbatim transcript of dialogue, showing what commands you typed, and that the computer gives you the answer.

Give the programmer all the input data, which you might think. If the program reads the file, you will probably need to send a copy of the file. If the program communicates with another computer on your network, you probably will not be able to send a copy of this computer, but you can at least say what is a type of computer, and (if you can) what software it is running.

"Works for me. So what’s wrong? "

If you give the programmer a long list of input and action, and they have launched their own copy of the program and nothing wrong happened, it means that you have not given them enough information. Perhaps the fault does not happen on every computer, their system and yours may be something different. Perhaps you do not understand what the program should do, and you’re both looking at exactly the same conclusion and think that it’s wrong, but they think it is correct.

Thus, also describe what happened. Describe exactly what you saw. Describe why you think that something that you saw is wrong; better describe exactly what you’d expect to see. If you say "and then she did it wrong, you omit important information

If you see an error message, tell the programmer to precisely and accurately what it was for the message. This is important! At this stage, programmers do not try to fix the problem: they are just trying to find her. They need to know what went wrong, and these error messages - the best way to describe it. Record the error messages if you have no easier way to remember them, but do not tell that the program generated an error message with no description of what it was for the message.

Especially if the error message contains a number, let the programmers know them. Do not assume that they do not make sense just because you can not see it. Numbers contain all kinds of information that can be read by programmers, and they often contain key information. The numbers contained in the messages because the computer is unable to report the error in words, but doing the best that can be done to provide you with important information.

At this stage, programmers effectively do the work of a detective. They do not know what happened, and they alone can not get close enough to see how it happens, so they are looking for clues that this prompt. Error messages, incomprehensible strings of numbers, and even unexplained delays are just as important as fingerprints at the crime scene. Keep them out!

If you use Unix, the program can produce a core dump (core dump). Core dumps - an important source of evidence, so do not throw them away. C on the other hand, most programmers do not like getting a giant dump files via email without warning, so ask before you send them to someone else. Also, keep in mind that the dump contains a record of all states of the program: any "secrets" (probably the program contains a private message or has to deal with sensitive data) may be contained in the dumps.

"Then I tried it…"

There are many things you can do when an error occurs. Many of them will make the problem worse. My friend at school deleted by mistake all my files Word, and before you call a knowledgeable person for help, she reset the Word, and then tried to run the derangement. None of this helped to restore the files, and this is mixed a disc to such an extent that no file recovery program in the world could not recover anything. If she had just left it as is, she had a chance.

Users like this are like the mongoose cornered: leaning back against the wall and staring death in the face, he vehemently attacked, because doing something would be better than doing nothing. It is not well suited to the type of problems that happen with your computer.

Instead of being a mongoose, be an antelope. When an antelope is facing something unexpected or frightening, it freezes. She stands perfectly still and tries not to attract attention, while she stands, she thinks and works out the best solution. (If antelopes had technical support line, they would call back at this moment.) Then, when it decides what can be done more safely, it does.

When something goes wrong, immediately stop doing whatever it was. Do not touch any buttons at all. Look at the screen, notice all the unusual and remember or write it down. Then, perhaps, begin pressing «OK» or "Cancel", depending on what appears to be safer. Try to develop a reflex - if your computer does something unexpected - freeze.

If you have coped with the release of a problem, either by closing the program or reboot your computer, it would be good to try to make sure that this problem occurred again. Programmers like problems that they can reproduce more than once. Happy programmers fix bugs faster and more efficiently.

"I think the tachyon modulation must be badly polarized"

Not only non-programmers write bad bug. Some of the worst mistakes I’ve seen are written by programmers and even good progammistami.

I once worked with another programmer who finds errors in your code and tried to fix them. Also, quite often he discovered the mistake he could not fix it and called me for help. I asked, "What happened?" He replied by telling me your opinion about what should be corrected.

This works well when his opinion was correct. This meant that he had already done some work and we can finish it together. It was helpful and efficient.

But quite often he was wrong. We worked for some time, trying to figure out why some particular part of the program produced incorrect data, and in the end, discovers that she has not done that for half an hour, we explored an excellent piece of code, but the real problem was somewhere else.

I am confident that with the doctor he would not have done. "Doctor, I need a recipe Gidroyoyodina." People know that it is not necessary to speak to the doctor: they say the symptoms, its discomfort, pain, rash and fever, and you let the doctor make a diagnosis that is the problem and what to do with it. Otherwise, the doctor declares you are a hypochondriac or crazy, and it will be correct.

It’s the same with programmers. Sometimes it is useful to inform their own diagnosis, but has always set out for symptoms. Diagnosis - is an optional extra and not an alternative to the provision of symptoms. Equally, make code changes to fix the problem is a useful addition to the error message, but no adequate substitute for it.

If a programmer asks you for additional information not invent it! One day someone told me about the error and I asked him to try the command, about which I knew she was not working. The reason that I asked him - I wanted to know which of the two error messages it displays. Knowing which email program generated - was key. He did not try to do it, he just wrote me, "No, it will not work" It took awhile to convince him to try.

Excellent that you have the intelligence to help the programmer. Even if your deductions are wrong, programmers will thank you for what you have at least tried to make their lives easier. But please also symptoms, and then instead you can make their lives more difficult.

"It’s funny, it did so a moment ago"

Say "intermittent fault" to any programmer and see how pogrustneet his face. The easy problems are those for which the play is enough to perform a simple sequence of actions. The programmer can repeat these steps in a well-observed test conditions and detailed look at what happened. Too many problems so do not do: it is programs that sboyat once a week or very rarely, or never sboyat when you’re trying to do it in front of a computer programmer, but always sboyat when you have a suitable deadline for the delivery of the work.

Most unstable failures are not truly stable. Most of them have some logic. Some might occur when the memory ends, some may occur when another program tries to modify a critical file at the wrong time, and some can only occur in the first part of each hour! (I actually saw this.)

Also, if you can reproduce the error, and the programmer can not, it may be because your computer and his computer into something different and this difference leads to an error. Once I had a program that is folded into a small ball in the upper left corner of the screen and sat there and sulked. But she did it only at a resolution of 800×600; everything was fine on my 1024×768 monitor.

Programmer wants to know everything that you can find out about the problem. For example, try on another machine. Try two or three times and see how often it fails. If an error occurs when you are doing serious work, but does not occur when you are trying to demonstrate the cause could be a great time to start or large files. Try to remember as many details of what you did with the program when it zasboila and if you see any patterns, mark them. Anything you can tell, can help. Even if it’s only assumptions (such as "There is a tendency to the fact that it falls more often when running Emacs»), it can not provide direct clues to finding the cause of the problem, but it can help the programmer reproduce it.

Most importantly, the programmer wants to make sure whether he has to deal with this unstable failure or a failure, characteristic of the machine. He wants to know many details about your computer, so that can make a conclusion about how it differs from his computer. Many of these parts depends on the particular program, it’s one thing you should definitely be ready to announce - the version number. Version number, version number, operating system and, possibly, the version numbers of other programs related to the problem.

"Then I loaded the CD into your Windows…"

It is essential that an error had been written clearly. If a programmer can not understand what you meant, you might as well have nothing to say.

I get error messages from all over the world. Many of them are from people for whom English is not native, and many of them apologizing for his poor English. Generally speaking, error messages, with apologies for bad English is actually very clear and helpful. Most ambiguous messages coming from the people for whom English is native, who believe that I understand them, even if they do not make any effort to be clear or accurate.

·         Be specific. If you can do something in two ways, specify how you used. "I chose the Load" might mean "I clicked on the button Download" or "I pressed Alt + W". Tell me what you did. Sometimes it matters.

·         Be verbose. It is better to give more information than less. If you say too much, the programmer can ignore some parts. If you say too little, he should go back and ask more questions. One of the error messages that I received, consisted of one sentence. Every time I asked for more information, the reporter said to me in one sentence. Obtaining a useful amount of information took me a few weeks, as was adding each time one small suggestion.

·         Be careful with pronouns. Do not use words like "this" or "box" when it’s unclear what they mean. Consider this: "I launched the application Foo. It kicked up a warning window. I tried to close it, and it fell. " It is unclear what the user tried to close it. Did he close the window with a warning or an application Foo entirely? This is a big difference. Instead, you can say "I launched the application Foo, which kicked up a warning window. I tried to close the warning window, and the application Foo fell. It is longer and with repetitions, but also clearer and harder to misunderstand.

·         Read what you wrote. Themselves, read the message and see whether you consider yourself, it is clear. If you bring a sequence of actions leading to the crash, try it yourself to make sure that you have not missed any step.

Summary

·         The first task of the error message - let the programmer see the failure with their own eyes. If you can not be with him, to reproduce the crash in front of a programmer, give detailed instructions so that he could reproduce the crash itself.

·         If the first task fails and the programmer can not see the crash itself, the second problem is the error message - to describe what went wrong.

·         Describe everything in detail. Identify what you saw. Also determine what you’d expect to see. Record the error messages, especially if they have the numbers.

·         If your computer does something unexpected, freeze. Do not do anything as long as you do not calm down and not do anything that you think might be dangerous.

·         Of course, try to diagnose the fault, if you think you can do it, but even in this case, you should also report symptoms.

·         Be prepared to provide additional information if needed to the programmer. He would not ask if it was not he needs. He is not intentionally annoying (inconvenient) Let the version numbers will be at your fingertips, because they probably need it.

·         Write clearly. Say what you have in mind and make sure that it can not be interpreted correctly.

·         First of all, be specific. Programmers like precision.

Click here to know more here : Software Testing Companies