Source: http://nckiki.cnblogs.com/articles/242883.html
Compile a valid bug report
--- Original Elisabeth Hendrickson writing tive bug reports
--- Kiki translation on
Have you been returned for more information?Bug report? Have you ever encountered a very serious error that was postponed to the next version to fix? Every bug report you submit is a written communication method with the project team regarding the software quality issues being tested. Generally, you are used for communicationProgramThe error capability is not reflected in the inherent severity of the error itself-but in determining whether the error needs to be fixed. If this is a terrible idea, you may think, "Wait! I hate writing. I am not good at writing. How can we determine the fate of errors by writing bug reports ?" It will attract everyone to believe that errors are for them-any normal-minded person should take the initiative to view a specific error is terrible enough to be repaired. Unfortunately, this is not the case. But the good news is that the ability to communicate effectively with software developers and project teams is not determined by your performance in College English courses. This is not about writing fluent prose with interesting words, nor about Excellent grammar and spelling. It is a way to clearly express errors with words that can only express your opinions. Too many words will render your point of view confused. Too few words can make others use their own assumptions to fill the gap-usually harmful to the software. If you are not sure about the errors, no matter how well your bug report is written, no one knows what the errors are. This articleArticleThis article mainly discusses the four ways you can start to improve people's chances of listening to the mistakes you 've found.
- Understand your audience
Without a doubt, any writing class will tell you who you are to write a bug report. Each bug report has at least two audiences: the people who have to fix the error and the people or groups who decide the fate of the error. Sometimes a person is responsible for the two jobs at the same time, but they are still two different listeners, but they happen to the same person together. Your first listener-the person who must fix the error needs to be clear and clear steps to reproduce the error. The more information, the better. For this purpose, we call this person a "Developer ". Developers need accurate information about what we operate and what we see. Your second listener-the person or group that decides the wrong fate needs to know the consequences if this error is not fixed. This listener needs refined statements to capture their attention and lead to discussions about the connection problems related to errors. For this purpose, we call him an "Incorrect Review Board ". In the process of fixing errors, your role is to help the error review board understand that the risk of not fixing errors far exceeds the risk of fixing errors. The more you understand how your developers and the error review board work, the more you can cut your bug report according to their needs. Try to understand your audience in private. If you can attend the incorrect Review Board meeting, try this. You will learn a lot about how your audience thinks.
- Select a good title
Generally, short sentences used to describe errors are called the title or description of errors. This is the most important part of the bug report. The members of the error Review Committee often use it to determine whether the error can be fixed later. If the title has no strength, Committee members may think that it is not worth too much time. (After all, more than 145 errors will be reviewed in the next two hours .) The following are some examples:
Okay.
: Crashed upon exit after timeout
Too long
: When the database is unavailable, you save the changes recorded.
,
Then, the program crashes when you choose to exit from the File menu.
Insufficient information
: Program crashed
Too vague
: A problem occurs when the database is offline. The title is changed to a method that provides the project team with check and investigation errors. Compared with data, words are easier to remember. People prefer to remember the error "cannot be installed in Windows 23423", rather than the error similar to "#". In the future, people will still use these keywords to search for errors. It is not easy to write a good and concise error title. Compared with other parts of the bug report, you should spend more time constructing the ideal error title. Be sure that the title is short enough to display completely (not broken) on the Display error screen and in reports generated by the defect tracking system ). Titles do not have to be perfect syntax, but should be short and insightful.
- Clearly written and clear steps
The steps you submit to developers should provide information on how to generate errors so that errors can be discovered and repaired. It also needs to provide the error Review Board with an environment where errors occur.
Unique and correct
:
1.
Run the client
2.
Find a record
3.
Change record but not save disk
4.
Offline Database Server
5.
Try to save the record
6.
An error occurred while receiving the timeout message.
7.
Exit the client
Result: Crash
Careless (there is a lot of room for misunderstanding
):
The database server is offline, saved, and then exited, and crashed.
Too much redundant information (cannot identify the most critical cause of the error)
1.
Run the client
2.
Query databases for new entries
3.
Open a browser
4.
In
Yahoo.com
Browse news
5.
Close your browser
6.
Select an entry
7.
From "Vegetables"
Change to "Fruit"
8.
Offline Database Server
9.
Try to save the record
10.
An error occurred while receiving the timeout message.
11.
Exit the client
Result: Crash In this example, the tester records everything he did before an error was found, but he didn't check if every step was necessary, for example reading news from Yahoo.com. If you write down the steps that are essential for generating errors, developers will rarely tell you that they cannot reproduce the errors, similarly, the Committee will rarely decide "no one will do that!" But what if every step is required? If an error occurs only after you execute steps that seem unrelated, record these steps in the bug report. You can write "required steps" after steps that seem to have no logical relationship, or you can add a comment at the beginning of the bug report: "Note-each step here is a necessary step to reproduce the error. Writing clear steps can also help in the repair verification process, especially when another tester performs verification.
- Explain the impact of the error, not just the symptoms
Some bug reports are misleading. The error surface shows that it is harmless, but if you check for the implication of the error, you find it a very serious problem. If you are on the error Review Board, which error will you support first? 1. The report on an annoying dialog box blocking applications 2. The report on application terminated upon exit is the same error. The difference lies in how testers compile the bug report. The "annoying dialog box" mentioned here refers to a window in the Windows operating system that cannot exit the process ("This windows application cannot respond to a request to end the task ..."). The tester found this problem when trying to shut down the machine rather than exiting the application. The application does not wait for input from the user. Therefore, exit fails for no reason. In fact, this symptom points to a deeper problem-the bug report on the "annoying dialog box" was nearly missed when the fix was postponed. This "annoying dialog box" bug report has two problems. First, it is not accurate. If the tester includes text in the "annoying dialog box" in the step, the decision maker can realize that the dialog box is a serious problem rather than a small disturbance. Second, this report does not identify other hidden problems with errors: The application is suspended.
Conclusion We all want to make our work different. We want to know that the final version of the software is better because of our hard work. Our ability to communicate errors is a deciding factor in our ability to influence the final version of the software as much as we want. Therefore, when writing a bug report, remember your audience, select a good title, clearly record the steps, and explain the impact of errors. Your bug report will be better because of your extra efforts and more bugs are fixed. In the end, we will achieve the expected result-so that the error can be fixed before it hurts the user.
