Why establish a defect management process?
In any software life cycle, the appearance of software defects is almost inevitable. The purpose of establishing an effective defect management process is to reduce the probability of software defects and greatly reduce the negative effects caused by software defects. Investment in defect management processes can greatly reduce the waste of manpower, financial resources and time due to rework/repair defects, while improving user experience or more user retention and product reputation, and can ensure more punctual delivery of products.
Before officially starting to talk about the construction of product defect management processes, we first introduce some basic concepts
What is the difference between a software bug and a defect?
What is a bug?
BUG was originally a computer term in the software industry, referring to the result caused by incorrect coding.
What is the flaw?
Defects in English: DEFECT. Defects refer to non-compliance with the originally defined business requirements, and their coverage is higher than BUG. Except for error codes, other problems that lead to non-compliance with the originally defined business requirements belong to the category of defects.
The two terms BUG and DEFECT have very subtle differences in English, but they are all errors that need to be fixed in the industry, so some test teams do not subdivide these two words.
When a tester executes a test case, he may encounter test results that are inconsistent with the expected results.
This inconsistency in test results is called a software defect. These defects have different names in different teams, such as errors, defects, bugs, problems, etc. In the following articles, we collectively refer to them as "defects".
Common terms in defect reports:
When reporting defects to developers, your defect report should include the following information:
-
Defect ID: the unique identification number of the defect
-
Defect description: Describe the defect in detail, including information about the module where the defect was found.
-
Software version: The version number of the software program that found the defect.
-
Reproduction steps: detailed steps and screenshots where developers can reproduce defects.
-
Defect submission date: the date the defect was submitted
-
Relevant documents: Through the comparison of related requirements, design, and architecture documents, it can be easier to understand, such as product requirements documents, related product prototypes or use case documents, etc.
-
Submitter: Who discovered the defect.
-
Defect status: the current repair status of the defect, we will introduce it in detail later
-
Fixer: The developer who fixes the defect
-
Defect close date: the date the defect was closed/resolved
-
Defect level: describe the severity of the impact of the defect on the software program
-
Defect priority: Priority is related to the urgency of defect repair. The severity priority can be high/medium/low, depending on the urgency of the impact of the defect repair on the application
What if there is no effective defect management process?
In fact, no matter whether the team spends time and energy to create a defect management process, the defect management process will always exist, but this process is not necessarily effective. I have seen some teams that do not have an effective process, but through oral or E-mails are used for defect management. These methods may cause many problems. Let me give you a simple example:
If defect management is carried out through oral or simple email communication as in the above situation, things will soon become very complicated. If you, as a test supervisor, want to control and effectively manage defects, you need to understand the life cycle of a defect and how Establish an effective defect management process.
Defect management process
This section will guide you on how to apply the defect management process to your project. Management defects can be divided into the following steps:
Step 1: Find BUG
In the BUG discovery stage, the project team should try to find the existing BUG before the product goes online. When the discovered BUG is confirmed with the colleagues of the development team, the status of the BUG should be changed to the accepted status.
In the above scenario, the tester found 15 bugs: Before the product was released, the tester found the bug, and then reported it to the project manager, and then the project manager told the developer to accept or reject the bug.
Let's look at another scenario: your test team found some problems on the BUGOUT website. They consider them to be defects and report to the development team, but there are conflicts.
At this time, what will you do as a test supervisor?
A) Agree that the testing team believes that it has defects
B) The test manager plays the role of a judge to determine whether the problem is flawed
C) Development team that agrees not to be defective
In this case, the test supervisor should play the role of a judge to decide whether the website problem is a defect. Or the team will discuss a conflict resolution plan and implement it according to the plan
Step 2: BUG priority classification
Defect classification helps software developers prioritize their tasks. This priority helps developers fix those very critical defects first. BUG priority classification can include the following:
Fatal: defects that need to be repaired immediately
Serious: It may cause great damage to the product
General: The defect affects the main characteristics of the product, and this defect reduces the quality of the product
Minor: The defect has little effect on the product
Let’s do a small exercise to classify the following defects into fatal, serious, general, and minor
1. The website performance is too slow
2. The login function of the website does not work properly
3. The GUI of the website is not displayed correctly on mobile devices
4. The website cannot remember the user's login session
5. Some links do not work
The recommended answer is given below:
1. Serious: Too slow website performance will cause great inconvenience to users
2. Fatal: If the login function is unavailable, it is equivalent to shutting out the user
3. General: The defect only affects mobile users.
4. Serious: This is a serious problem because the user can log in but cannot perform any further actions that require verification of user information.
5. Minor: For developers, this is a simple solution, users can still visit sites without these links.
Step 3: Resolve/fix the bug
Once the defect is accepted and classified, you can follow the steps below to fix the defect.
Allocation-Schedule-Fix BUG-Report Solution
Assign: Assign to developers or other technicians to repair, and change the status to "Responsive".
Schedule: The developer is responsible at this stage. They will create plans to fix these defects based on their priority.
Fixing BUG: When the development team is fixing the defect, the test manager will track the process of fixing the defect and compare it with the above plan.
Report solution: Obtain the developer's resolution report when fixing the defect.
Step 4: Verify whether the BUG is fixed
After the development team fixes and reports the defect, the test team verifies whether the defect has been truly resolved.
For example, in the above scenario, when the development team reports that they have fixed 61 defects, your team will test again to verify whether these defects are really fixed.
Step 5: Close the BUG
Once a defect is resolved and verified, the defect will be changed to a closed state. If not, you have notified the developer to check the defect again.
Step 6: data report
The management has the right to know the defect status. They must understand the defect management process in order to support you in this project. Therefore, you must report the current defect status to them in order to get feedback from them.
Important defect KPI indicators
Management master Drucker once said: You can't manage things that you can't measure. Defect management is the same, you need to have some reference indicators in order to measure the management effect. You can consider using the following two simple indicators to measure the execution effect of your test team
DEFECT REJECTION RATIO (DRR): (Number of rejected defects/Number of defects reported by the total testing team)*100%
Defect Leakage Rate (DEFECT LEAKAGE RATIO, DLR for short): (Number of missing defects/Total number of defects)*100%
Let me give a simple example:
BUGOUT's testing team found 50 bugs during a product upgrade test of BUGOUT and fed them back to the development team, 5 of which were verified to be not bugs. After the new version was launched, 10 feedback related to this upgrade were received and confirmed that they were all BUG.
Defect rejection rate (DRR)=5/50=10%
Defect omission rate (DLR)=10/(50-5+10)=18.18%
The smaller the value of DRR and DLR, the better the quality of test execution. What is the acceptable range of ratios? This range can be defined and accepted in the project goals, or you can refer to the indicators of similar projects.
Written at the end,
if you are interested in python automated testing, web automation, interface automation, mobile terminal automation, interview experience exchange, etc., you can follow the WeChat official account: [Programmer Erhei] to get an interview with a software test engineer data! My learning exchange group: 785128166 There are technical experts in the group to exchange and share~
If the article is of interest to you, please reach out to make a fortune and give me a like. Thank you for your support. Your likes are my motivation for continuous updates.