Yes, there are bugs in any software, even our own flaws, because programmers are just ordinary people, and as long as the person will make mistakes. When someone encounters a software bug while using the software, you need to use your email to form a bug and then send it to the developer. Developers can fix problems by locating problems and reproducing problems based on the report.
But in many cases, it's hard for developers to understand the bug report that the user submits, because the sender doesn't know what we need, how to communicate with the developer, and how to write a bug report, in the article I wrote, I'm going to show you how to write a clear bug report that allows developers to understand, reproduce, and fix problems.
Why should I send a bug report
Bug reports can help our developers in a number of ways.
They can tell us things we're not aware of.
They can find new features we might not have thought of.
They can help us feel how our customers use our software so that we can do it better
Without these bug reports, we don't know where it went wrong, and we need it just like you need software to sing and dance.
When to send a bug report
In short, the quicker the better, the more detailed is:
Send an error report when you see an error message
Send a report when the screen is blank or the data is missing
Send a report when the program does not have the expected results
Send a report when a program crashes, freezes, does not respond, or responds slowly
Send a report when the program returns an error result
Send a report when you don't get the results you want
Send a report If you don't know what to do
If you don't like the way software is done, or the software interrupts you, send the wrong report
Send a report if you want to implement a workaround in the system
What is required for defect reporting
The bug report should contain a lot of information, the more information you provide, the better it will be, for developers, like me, provide a plain text file template for you to fill and email to me, of course, there are forms, but most expect you to make up a copy and send it to me. Here are some of the parts that must be included and how to write each section well:
Title: Create a short title to make the question look clearer. "Application Crashes" is a very annoying headline because it doesn't have enough information to include in the report. Instead, the title should contain the error message and the message code, or the name of the result and what you were doing when it failed. For example: Error 402: Access denial When you click the "Send Mail" example, the context information for the defective system is provided.
Poor: "Program crashes", "Error", "Bug"
Good: 5c79 error when printing from ' Kifu ', ' Kifu honors ' report is empty
Product: Identify the product by name and tell you which version you are using. Most software contains version information. Version information for Web applications is usually in the footer.
Poor: "Your Application"
Good: "Kifu V1.01″
Platform: Tell us what platform the software is running on. In particular, the name and version of the operating system and the browser name version. Especially for Web applications, this information is important to us.
Poor: Windows
Good: "WINDOWS7,IE9"
Whether it can reproduce: Some annoying bugs are intermittent, and we want to know beforehand if we are dealing with a supernatural event or when a bug arises.
Poor: Leave blank
Good: "Every Time", "accidental", "Do not reproduce"
Description: This part is where a lot of people don't know how to describe the problem and include the following in the description:
Summary: Use concise language to summarize what you're doing when a bug comes up. Starting from the context, in which part of the operation is applied. Focus on what the software does when you do it?
Poor: "The system is not available"
OK: On the Honor Report page, click Print button, but the reports are empty.
What happened: Step by step describe what you're doing. Why do you think it's wrong when a bug comes up? Print out the name of the menu, the title of the page, the button you clicked on, or the name of the link. Doing the same thing is not the same error.
Bad: Blank report
OK: "Click ' file/save as ... ', ' Save ' dialog empty pop-up, then click ' OK ' button, but file not saved"
What is wrong: If the error message appears, copy paste the entire information, which is more conducive to tracking the error.
Poor: "There is a mistake, click it always read"
Good: "Error 403: Access Denied"
The steps to reproduce: If you can make a bug reappear, that's great, and it helps a lot. Step-by-Step describes how to reproduce a secondary bug.
Poor: "Print is not available"
OK: "From the ' Honors" page, click the ' Print button '
Expected results: Describe what you expect to happen when a bug occurs, this section is especially useful if the program doesn't happen the way you expect it to, because it's weird.
Poor: "I look forward to working properly"
Good: "I expect to see the PDF file of ' honors Reports '"
The real result: what happens when a bug happens, what is wrong, why it is wrong, or if it is thrown, what is wrong.
Poor: "No use"
Good: "I received a PDF file that was empty, or ' 403 error, Access Denied '"
Attachment: If you know how to screen, do it, attach a short error, screenshots can be before or after the error, our developers can see what happened. If the application has a crash log, it is likewise attached.
Contact: Attach your name and email, we can let you submit the report in a timely manner, we can not understand the description of the problem, but also to ask you, if you forget to contact the way, we will not be able to contact you, and can not fix the bug.