[Reprinted] basic concepts of software defect management

The author's source is unknown.

To understand Software defects, we must first understand the concept of Software defects, secondly, the detailed characteristics of Software defects, and finally its attributes, A higher level is a tool for learning to manage software defects.
1. first introduce the concept of Software defects
Software defects refer to the defects in the system or system components that cause the system or components to fail to implement their functions.
2. Detailed features of Software defects
A. Single and accurate
B. reproducible (requires accurate steps for Software defects)
C. Complete and unified
D. short and concise
E. Specific conditions
F. Complete supplement
G. No comments
3. Attributes of Software defects
Attributes of a software defect include the defect identification, type, severity, likelihood of occurrence, priority, status, origin, source, and cause.
The following describes these attributes in detail:
A. defect identification: it is the unique identifier for marking a defect. It can be represented by numerical numbers;
B. defect type: function, user interface, document, software package, performance, system "Module Interface
Function: affects the defects of various system functions and logic;
User Interface: affects user interface and Human-Computer Interaction features, including screen format, user input flexibility, and result input format;
Documentation: affects release and maintenance, including comments, user manuals, and design documents;
Software Package: errors caused by software configuration library, change management, or version control;
Performance: does not meet the measurable property values of the system, such as the execution time and transaction processing rate;
System "Module Interface: with other components, modules or device drivers Program , Call parameters, control blocks, or parameter lists do not match or conflict.
C. Severity of defects: fatal, ceritical, Major, minor)
Fatal: all major functions of the system are completely lost, user data is damaged, and the system crashes, hangs, crashes, or threatens personal safety;
Severe: The main functions of the system are lost, data cannot be saved, and secondary functions of the system are completely lost. The functions or services provided by the system are obviously affected;
General: the secondary functions of the system are not fully implemented, but do not affect the normal use of users. For example, the prompt information is not accurate, the user interface is poor, and the operation time is long;
Relatively small: it makes the operator inconvenient or in trouble, but it does not affect the operation and execution of functions, such as some small problems that do not affect the product understanding, such as incorrect text Arrangement and other small problems
D. Possibility of defect generation: Always, usually, sometimes, rarely
Always: This software defect is always generated, and the frequency is 100;
Generally, this software defect is usually generated according to the test case, and the frequency is about 80-90;
Sometimes: according to the test case, sometimes this software defect is generated, the frequency is about 30-50;
Very few: according to the test cases, this software defect is rarely generated, and the frequency is about 1-5.
E. Priority of defects: immediate resolution, high priority, normal queuing, and low priority
Immediate solution: as a result, the system is almost unusable or the test cannot be continued, so the system must be repaired immediately;
High priority: serious defects that affect testing should be given priority;
Normal queuing: Defects need to be queued up for repair;
Low priority: defects can be corrected when the developer has time.
F. defect status: activated or opened, corrected or repaired, closed or unactivated, re-opened, postponed, retained, non-reproducible, more information required
Activate or open: the problem persists.Source code Confirm "submitted defects" and wait for handling, such as newly reported defects;
Corrected or fixed: defects that have been inspected and repaired by developers have passed the unit test and are considered to have been resolved but not verified by testers;
Closed or inactive: status after the tester verifies that the defect does not exist;
Re-open: the status after the tester verifies that the defect does not exist;
Delay: This software defect can be solved in the next version;
Retention: defects that cannot be repaired by developers due to technical reasons or third party Software defects;
Non-reproduction: developers cannot reproduce this software defect and testers need to check the steps to reproduce the defect;
More information is required: developers can reproduce this software defect, but developers need some information, such as the log files and images of the defect.
G. Origin of Software defects: Requirements, architecture, design, coding, testing, and users
Proportion of Software defects in the group building lifecycle: 54 in the requirement and architecture design stage, 25 in the design stage, 15 in the coding stage, and 6 in the others.
H. Source of Software defects: Requirement Specification, design document, system integration interface, data stream (database), Program Code
Requirement statement: problems caused by incorrect or unclear requirements statement;
Design document: the description of the design document is inaccurate. Inconsistency with requirement statement;
System integration interface: defects caused by unmatched system module parameters and lack of coordination between development teams;
Data Stream (database): defects caused by data dictionary and database errors;
Program code: defects caused by purely coding problems.
I. Root Cause of defects: testing strategy, process, tools and methods, team members, lack of organization and communication, hardware, software, and working environment
Testing strategy: Wrong testing scope, misunderstanding of testing objectives, and exceeding testing capabilities;
Processes, tools, and Methods: Invalid requirement collection processes, fruit risk management processes, unused project management methods, no estimation procedures, and invalid change control processes;
Team: The project team has different responsibilities and lacks training. Lack of experienced project teams, lack of morale and motivation;
Lack of organization and communication: lack of user participation, unclear responsibilities, and management failures;
Hardware: Incorrect hardware configuration, lack of hardware, or processor defects, leading to loss of arithmetic precision and memory overflow;
Software: resources cannot be released due to incorrect software settings, lack of software, or operating system errors, tool software errors, compiler errors, and Millennium Bug issues;
Working environment: Organization adjustment, budget change, and poor working environment, such as heavy noise.
4. Learn to use tools to manage Defects
Such as TD, bugfree, and bugzille.