Bug Report submission Specification

First of all, the bug's test specification should be established in the company's official documentation.
This recommendation is an informal document, some of which may be incorrect, some of which may need to be debated, and even some of the content is in conflict with corporate norms. If you find a problem, ignore the content of this article directly.
The purpose of this post is only the work of some of the phenomena recorded, can be easily standardized to make everyone work easy and efficient.
Follow-up continue to add changes, please also add amendments.

Secondly, this post also only to fill in the behavior of the bug report a few grooming and suggestions, can not replace the formal bug test process or quality management process.

Content:

Fill in the bug report, which may be a dedicated tester or developer, or even a temporary help or end user.
Finding bugs and fixing bugs is a very important task. The goal is for the software to be able to run safely and stably, the person who submits the bug is consistent with the person who solves the bug, not the opposite, not the trouble.

Test work is very complex and heavy, found that the problem is only the first step, more important is to determine whether it is a bug, is not reproducible, and the difference between the correct results.
The final submitted bug does not allow the person to repeat too much work to reproduce, and not to let the fix guess or test power. The quickest way to fix a problem is to find the key.
If the fix spends too much time figuring out the recurrence of a bug report, it's best to show it directly to him, which is the most effective way.

Based on these understandings, we want to reach an agreed norm.

Submitter Specification Recommendations:

1.
Submitting a bug is against a real flaw. Those occasional bugs, the submitter tries to find the real reason for the recurrence. If possible, repeat as much as possible on 2 different terminals. If there are no 2 terminals, at least 2 kinds of browsers or 2 virtual machines and other ways to reproduce the simulation.
2.
If this is a browser-compatible issue, determine which type of browser, version number, language, and how to set up the bug report after the repro step.
3.
The description is clear. Some bug is that the demand is not satisfied, but no other crash results oh appear, try to "expect" the content and "actual" situation,
For example, a bug, a button click after the "demand" is the open window, the actual result is to go to another address. The transfer address is wrong, tell the person who fixes it.
Instead of reporting: This Click button then goes to a new address.
The fix sometimes understood that the requirement was to move to a new address, and what he saw was the result. Fix this may have to be carefully contrasted with the requirements specification in order to know that this is a mistake. The demand in his memory might be to move to a new address.
Suggestion written: "Demand" is the open window, "current" bug is to go to another address.

4.
Narrow the range. If you can position the bug in a certain range, it reduces duplication and positioning, and makes it clearer what bugs are critical.
For example, if the bug report is such a report, the fix will be a forehead Khan.
Forum website does not go!
The scope of this bug is too wide. There are a number of specific bugs can be described as the site does not go.


intranet can be on, outside the network can not be on.
with IE browser can be on, with Chrome can't on
the page of the website cannot open, wait for
Web page opened error, all English, can not display useful text.
The Web page of the website can be opened, but there is no login section.
Website Login box correctly fill in the user name password, or prompt "User name password can not be verified through"
Website Login box correctly fill in the user name password, no response.
After the website Login box correctly fills in the user name password, the page becomes the error message.


Therefore, the bug report also has the quality, must have qualitative, not quantity. This is also the reason why the tester cannot calculate the amount of work in the number of bugs.

5.
If there are some small problems with the interface, please put the problem you find. , be sure to indicate the error in a marked way.
If possible, the correct one is provided, and the corresponding position is clearly marked.

6.
Multiple associated bugs, try to submit each bug separately, and have a clear association with Bugfree. The decomposition of the defect also reflects the work of the tester in place.

Fix Specification Recommendations:
1.
Respect the work of the bug submitter and treat each bug seriously.
2. If there are unclear bug reports, contact the submitter as soon as possible in order to reproduce the bug and agree on the agreement.
3.
If the problem belongs to someone else, forward it as soon as possible.
4.
More practice "Look for different", "going", "repeatedly see" and other games, improve eyesight. In particular, a pixel or 1px line flaw in a few faces.
The Human resources department is recommended to join the test and record in the entrance examination.

Bug Report submission Specification