Original software defects

Rules that satisfy a software defect (one can be satisfied):
(1) The software does not implement the function of the product specification requirements
(2) The software has appeared the product manual indicates the error which should not appear
(3) The software realizes the function not mentioned in the product specification.
(4) The software does not implement the product specification, although not expressly mentioned but should be achieved by the goal
(5) The software is difficult to understand, difficult to use, slow to run or-from the point of view of the tester-the end user is considered bad

Basic information on defects
(1) Defect title, description of the title of the defect;
(2) The severity of the defect, describing the severity of the defect. Generally divided into "fatal", "serious", "General", "recommendations" 4 kinds;
(3) The degree of urgency of the defect, describing the urgency of the defect. From 1~4,1 is the highest priority level;
(4) The defect author, the name of the defective author (e-mail address);
(5) Defect submission time;
(6) The defect belongs to the project/module. The project and module that the defect belongs to, it is better to be able to locate the module more precisely
(7) The defect designates the settlement person. Defect specified by the resolution person, in the defect "submit" status is empty, in the defect "distribution" status by the project manager to specify the relevant developer modification;
(8) The defect specifies the resolution time. The developer designated by the project manager modifies the deadline of this defect;
(9) Defective handling person. The person who eventually deals with the defect;
(10) Description of the defect treatment result. The description of the processing results, if the code has been modified, the need to reflect the changes here;
(11) Defect processing time;
(12) Defect verifier. Verification of the defects to be handled;
(13) Description of the defect verification result. Description of the validation results (passed, not passed);
(14) Defect verification time;

Main contents of Defect report
(1) Problem report number: Easy to manage, give unique number, number sequence can be specified according to requirements and management requirements;
(2) Title: the title in a concise way to convey the basic information of the defect, to be brief and unique;
(3) The Reporter: the original author;
(4) Date of report: Date of First report;
(5) Name of the program (or component): the subject of the distinguished test;
(6) Version number: The test may span multiple versions, providing version information to facilitate defect management;
(7) Configuration: Found the hardware and software configuration of defects, operating system type, processor, RAM size, browser loading, running other programs, etc.;
(8) Types of defects: such as code errors, design errors, document mismatches, etc.;
(9) Severity: Describes the severity of the reported defect;
(10) Priority: A developer or manager to confirm, based on the importance of repairing this defect;
(11) Keywords: convenient classification to find defect reports, can add keywords at any time;
(12) Description of Defects: Detailed description of the problem found, the description to be in-depth, concise is still the most important.
(13) The repro step: must be limited, and the information described is sufficient for the reader to know that the correct implementation can reproduce the flaw;
(14) Result comparison: What is expected and what actually happens after the defect step is performed.

Original software defects