1. Basic concepts and related terms of software testing defects

  1)Defect( Defect): It refers to the deviation existing in the software, which can be activated and exists in the software in a static form, which is equivalent to Bug. 
  2)Malfunction( Fault): When the defect is activated, the state in the software operation can cause accidents. If it is not handled, it can produce failure, which is a dynamic behavior.
  3)Lapse( Failure): The external abnormal behavior results produced by the software running are inconsistent with the user's needs, the functional capability is terminated, and the user is unable to complete the required application.
  4)Bug: Any kind of problem or defect in the computer system or program that destroys the normal operation ability can be called“ Bug"；Sometimes it also refers to the deviation between the final running time and the expected result of the software product caused by the interior of the software product.
  5)Defect report: it refers to the written report submitted after the defect is found to be invalid during the test execution, which is provided to the developer as the basis for locating the defect.

2. Basic process of software defect management

The following figure is a simple BUG tracking flow chart:

  1)The oval is marked with roles (tester BUILDER Staff, developers, experts (consultation)
  2)Histogram 1: publisher, which generally stores the latest software version
     Histogram 2: RAID/BMS，yes Bug In the management system, testers should submit problems to this system
     Histogram 3: mail server, tester BUILDER Personnel, developers and experts communicate by email.

3. Purpose of software defect management

  1)Ensure the consistency of information;
  2)Ensure that defects are effectively tracked and solved, shorten communication time and solve problems more efficiently;
  3)Get the right Bug Information, which is conducive to defect analysis and product measurement, and strengthen the visualization of project situation.

4. Related attributes of software defects

@1. Defect discoverer

When submitting defects, testers are generally test discoverers, which is convenient for statistical analysis of testers' abilities and performance appraisal of the company.

@2. Defect discovery time

Defect discovery time is a statistical counting point or data point, which is convenient for the person in charge of the enterprise to choose the appropriate product release time.

@3. Status of software defects

  1)New: The initial state of the defect (problem found, problem submitted, and after the problem is submitted, the defect is in New (status of)
  2)Open: The developer starts to modify the defect (the tester submits the problem, and the developer accepts and starts to modify the problem)
  3)Fixed: The developer has modified the defect
  4)Closed: Pass the regression test (the tester performs the regression test, and the regression test passes. The question is changed to Close Status)
  5)Reopen: Regression test failed (if the tester performs regression test and fails the regression test, the problem is changed to Reopen Status)
  6)Postpone: Postpone modification
  7)Rejected: The developer thinks it is not a program problem and rejects the defect
  8)Duplicate: With submitted Defect repeat
  9)Abandon: cover Reject and Duplicate of Defect，After the tester confirms that it is not a problem, it will Defect Set to this state

Ideal defect process: from new state - > Open - > fixed - > closed state.

@/4. Severity of defect

From the perspective of users, it refers to the impact of bugs on users and systems.

The severity of software defect refers to the damage degree of software defect to software quality, that is, how the existence of software defect affects the function and performance of software. We can simply divide the severity of software defect into four levels: fatal, serious, general and prompt.

  1)Fatal defects: for example, the unexpected exit of software or even the collapse of operating system, resulting in data loss.
  2)Serious defects: the system cannot meet the basic business requirements and there is no convenient and available work area. Serious non-compliance in performance, function or use, such as multiple function failures caused by single function failure.
  3)General defect: the system can meet commercial requirements. There is a fast and convenient work area for use. Performance, function or use are not seriously substandard, such as failure of a single function of the software.
  4)Tip: minor modification. I hope to make suggestions. It's best to correct it, but it's not necessary. It will not have a significant impact on the accuracy or practicability of the release

@5. Priority of defects

From the perspective of development / project, comprehensively weigh the time, cost, technology and risk of modifying bugs to determine the order of Bug modification.

  1)Priority 0( Priority 0)
     Such software defects must be solved within 24 hours
  2)Priority 1( Priority 1)
     Such software defects must be repaired before the product can be released or the most important goal contained in the user experience can be achieved. They need to be modified within 1-2 days
  3)Priority 2( Priority 2)
     Software defects should be fixed within 2-4 days
  4)Priority 3( Priority 3)
     If you fix this defect, it will be better. You'd better fix it within a week
  5)Priority 4( Priority 4)
     Modify or not modify within the release cycle

Difference between Severity and Priority

  1)In the software Bug The effect is not automatically associated with the priority of repairing it. A serious Bug Maybe it's the kind of one%It is also unlikely to happen for users to crash the software bug. Then its priority is also higher than that caused by misoperation, which requires each user to retype part of the input at a time Bug The priority of is lower.
  Therefore: it needs to be tracked separately Bug Priority and severity, and then make appropriate repairs. Bug The importance of is determined by the project, which is different from that of customers Bug Your perception. In some cases, track urgent or defined according to the customer's point of view Bug It is also very meaningful.
  1)The priority is related to the project schedule and the severity is related to the standard. Priority indicates the objects that need priority and attention; Priority is constructed from the order of importance; Compliance with a high-level criterion, such as code severity, or the need to be strict. The words priority and severity appear in Bug Tracking. A commercial software tool for problem tracking and management is feasible. These tools, as the test engineers input item by item, give the team complete information so that the developers can understand Bug，Understand? Bug The severity, reproduce it, and fix it. Repair is based on priority and severity. Serious problems are defined according to the customer's risk assessment and recorded in the selected tracking tool. many Bug The software will "seriously" affect the project progress, and in turn, it can also lead to reassessment and discussion of "priority".

@6. Type of defect

  1)From the perspective of quality characteristics, there are defects in function, performance, safety, ease of use and reliability;
  2)From a functional point of view, there are errors:( Errors),Omission( Missing),Superfluous( Extra),Optimizeable( Improvement/Enhancement/Suggestion)Defects;
  3)The causes of defects include: requirements specification SRS,Design problem, coding problem, requirement change, design change, configuration problem and test problem

@7. Version of defect

  1)Version of defect found (must be stated)
  2)modify bug Version of
  3)Version of regression test (usually the latest version)

@8. Defect modification date

It is a parameter that mainly evaluates developers.

5. Defect report writing

@1. Complete defect report

A complete and high-quality defect report includes three aspects: simple description, detailed description and relevant attachments.

  1)Simple description
     Use a simple, supportive statement to describe the problem clearly
  2)Detailed description
     *1*Describe the basic environment of the problem, including the operating system, hardware environment, network environment and the running environment of the tested software
     *2*Use concise language to describe clearly the operation steps and data used by testers when the software is abnormal
     *3*If from GUI It can reflect the abnormality of the software. The interface is intercepted by copying the screen and pasted in the problem list
     *4*Relevant log files when the software under test is running
     *5*Based on the above information, the tester can give a simple analysis of the problem
     *6*Version of software under test
     *7*Status, severity
     *8*Submitted by
  3)Relevant attachments
     *1*GUI Copy screen picture of
     *2*Relevant log files of the software under test

@2. Example and analysis of excellent defect tracking sheet

  1)Simple description
     -Arial,Wingdings and Symbol Fonts can destroy new files.
  2)Detailed description
     *1*The software test environment is windows 2000 sp4
     *2*start-up WordEdit Editor, and then create a new file
     *3*Enter four lines of text and repeat“ The quick fox jumps over the lazy brown dog"
     *4*Select all four lines of text, then select the font drop-down menu and select Arial
     *5*All text is converted into control characters, numbers and other obvious random binary data
     *6*Repeat three times and the results are the same
  3)Relevant attachments
     *1*Document before formatting
     *2*Document after format conversion

@3. Writing points of defect report

  1)Defect title
  2)Defect reproduction steps (try to reproduce the fault for 3 times)
  3)Defect type
  4)Defect priority
  5)Defect severity