Knowledge about Software defects

[Definition of Software defects]

First, the definition of a bug: any problem or defect in a software program that damages the normal running ability can be called a "bug ".

(1) The software does not meet the requirements in the Software Product Requirement Specification.

(2) The software has encountered errors not indicated in the Software Product Requirement Specification

(3) The software function is beyond the scope specified in the Software Product Requirement Specification.

(4) The software does not meet the requirements not specified in the software product manual but shall meet

(5) problems that testers think are hard to understand, difficult to use, slow to run, or hard to use by end users

 

[Software defect level]

Suggestion: some suggestions on availability, such as font color, do not affect usage.

Tip: some minor problems, such as incorrect typos and incorrect text layout, have almost no impact on functions, and software products are still usable.

GENERAL: minor errors, such as loss of secondary function modules, inaccurate prompt information, poor user interface, and long operation time.

Severe: a serious error indicates a false statement indicating that the function module or feature is not implemented, the main function is partially lost, And all secondary functions are lost or fatal.

Fatal: a fatal error may cause system crashes, crashes, data loss, and complete loss of main functions.

 

[Software defect status]

All defect management tools, such as bugfree and Jira, know that bugs are in the following states: new, accept/handle, reject, fixed, closed, re-opened, and suspended. The jump between statuses is shown below:

 

 

[Software defect handling]

The knowledge above can be found on various websites and books. However, in actual tests, testers must strictly follow the test procedure, check whether the developer suspends or suspends a bug without communication. In addition, when the software is released, the bug is rarely fixed to 100% and then released, so how can we assess whether a release can be made even if there are bugs left behind?

1. defect suspension rate

First, when a project is released, the defect suspension rate cannot exceed 15%, and the suspended bug also needs to be evaluated to have a great impact on the user, such as a latency problem, the latency exceeds 15 s. In principle, such bugs cannot be suspended and must be optimized. In addition, the test suggestions in the test report can be described as follows:

Ü full release: applicable to serious and fatal hanging bugs without hanging bugs or with no high reproduction rate.

Ü phased release is recommended: Suitable for low (lower than 50%) reproduction rates of serious and fatal hanging bugs, or users are not easy to perceive.

Ü not recommended for release: Applicable to pending serious critical bugs, or interfering with user experience.

2. Impact of legacy bugs

In the report, testers should make a rough assessment of the impact of the remaining bugs, the focus is on the reproduction probability of bugs, the impact of bugs on users, and whether the bug will trigger the use of other functional modules.