Before the formal start talking about building a product defect management process, we first introduce some basic concepts:
Software Bug and Defect What is the difference?
What is Bug?
Bug was originally in the computer software industry terminology, it refers to the results due to errors caused by coding.
What flaw is?
Defects English: Defect, defect is not in line with business requirements originally defined, its coverage is higher than the Bug, in addition to the error code does not meet the business requirements lead to other problems initially defined is a fault category.
The two terms in the English Bug and Defect has a very subtle difference, but the industry is in need of repair errors, so some team does not test these two words do segments.
When the testers execute test cases, he may encounter inconsistent with the expected results of the test results.
This results in inconsistencies referred to as software defects. These defects have different names, such as errors, defects, Bug, problems in different teams.
Bug reports should include information on:
When the feedback defect to the developer, your bug report should contain the following information:
- Defect ID : defective unique identification number
- Defect Description : Detailed description of defects, including defects module discovery information.
- Software Version : find the version number of the software program defects.
- Steps to reproduce : the detailed steps, and developers can reproduce the defect screenshots.
- Defective filing date of the date of submission of defects:
- Related documents : The relevant requirements, design, architecture, documents and contrast can be easier to understand, such as product requirements documents, related product or prototype use cases and other documents
- Author : Who discovered the defect.
- State of defects : Defect current state of repair, we will detail later
- Repair man : repair the defect developer
- Defects DATE : date the defect is closed / resolved
- Defects rating : Describe the impact of the defect on the severity of the software program
- Defect priority : the urgency of the related priorities and bug fixes. The severity of the priority may be high / medium / low, depending on the urgency of repairing defects affect the application of
Without effective defect management process happen?
In fact, regardless of whether the team has spent time and effort to create a defect management process, defect management process is always exist, but this process is not necessarily effective, I've seen some teams did not have an effective process, but through verbal or Mail way the defect management, these methods can lead to many problems, here I give a simple example:
If the same situation as above by oral communication or Simple Mail defect management, soon things will become very complicated, if you as a product manager, you want to control and effective management of defects, you need to understand the life cycle of a defect and how establish an effective defect management process.
Defect Process Management
In order to effectively manage defects, you need to build an effective defect management process, in order to avoid the above example, this chaotic state of disorder. This section will guide you how to defect management process is applied to the project. Management deficiencies can be divided into the following steps:
(1) detect defects: New
Usually there are defects in accordance with the test cases for testing team step, if not properly by the use cases into defects. But many teams and there is no specific test team, so it may feedback information from different teams or from external users to submit questions defects created. These defects defects feedback status should be "new."
(2) open
When the QA testing team or any other team the same duties identified defects feedback, such as can reproduce, the confirmation is a feedback defect, and waiting for assignment to the development team.
(3) distribution
When the test team confirmed the defect, the problem should be allocated for defect localization and repair work to the development team.
(4) refuse
If the development team is not considered a defect submit up real defects, such as some file caching, network load caused by failures due to other defects should state marked as "rejected" and assigned back to the test team. The test team need to re-test or provide more information about the defect.
(5) Repeat
If the defect is the development team received duplicate or similar defects in other ongoing defect status should be changed to "duplicate"
(6) Extension
部分不紧急的缺陷问题，可能会随着日后的产品迭代中进行修复。对于这类缺陷应当标注为“延期”。在这里要注意，并不是所有缺陷都需要立即进行修复。每个缺陷问题在严重程度，影响范围均有不同，因此优先修复的等级也不同。我会在下一篇文章中单独讲解制定优先级别的方法。
（7）等待测试
当开发团队修复缺陷后，应将缺陷状态标记为等待测试并由测试团队进行测试。
（8）关闭
在测试通过后，缺陷状态修改为“关闭”或者完成。
（9）重新开启
如果缺陷修复后并没有通过测试，应标记为重新开启，并重新启用分配流程。
重要的缺陷KPI指标
管理学大师德鲁克说过：你无法管理那些你无法衡量的事情。 缺陷管理也是一样，你需要有一些可供参考的指标，以便衡量管理效果. 您可以考虑使用以下两个简单的指标来衡量您测试团队的执行效果：
- 缺陷拒绝率 (Defect Rejection Ratio, 简称DRR)：（拒绝的缺陷数量/总测试团队报告的缺陷数量）*100%
- 缺陷遗漏率 (Defect Leakage Ratio, 简称DLR)：（遗漏的缺陷数量/总的缺陷数量）*100%
下面我举一个简单的实例：
Bugout的测试团队在Bugout的一次产品升级测试中，发现了50个Bug并反馈给开发团队，其中5个经过核实并不是Bug。新版本上线后，收到与本次升级相关的问题反馈10条并确认均为Bug。
缺陷拒绝率（DRR)=5/50=10%
缺陷遗漏率（DLR)=10/(50-5+10)=18.18%
DRR和DLR的值越小，测试执行的质量越好。 什么是可接受的比例范围？ 可以在项目目标中定义和接受此范围，也可以参考类似项目的指标。
