Detailed Arrangement of Software defects

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 defectsIt refers to the defects in the system or system components that make the system or components unable 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 a unique identifier for marking a defect. It can be represented by numerical numbers;

B,Defect type: Functions, user interfaces, documents, software packages, performance, system/module Interfaces
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: it does not match or conflict with other components, modules or device drivers, call parameters, control blocks, or parameter lists.

C,Severity: 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 defects: Always, usual, sometimes, and seldom
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 test cases, sometimes this software defect is generated at around 30%-50%;
Very few: According to test cases, this software defect is rarely generated, and the frequency is about 1%-5%.

E,Priority of a defect: Immediate resolution, high priority, normal queuing, 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: Activation or activation, corrected or repaired, disabled or not activated, re-opened, postponed, retained, non-reproducible, more information required
Activate or enable: the problem has not been solved. If the problem exists in the source code, confirm the "submitted defect" and wait for processing, such as the newly reported defect;
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
The proportion of Software defects in the group building lifecycle: 54% of requirements and architecture design phases, 25% of design phases, 15% of coding phases, and 6% of others.

H,Source of Software defects: Requirement statement, 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,Defects: Testing strategies, processes, tools and methods, teams/persons, lack of organization and communication, hardware, software, and work 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/person: 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.