为什么你的改Bug之路漫长而又艰辛?
为了能够减少二次Bug率,一般组织都有一套Bug跟踪流程用来确保Bug修改的正确性。
下面是一个典型的Bug跟踪流程。
登记Bug -> 原因分析 -> 修改方案 -> 影响性分析 -> 修改 -> 测试 -> 测试组再测试。
这个Bug跟踪流程基本上会有一个较高的Bug率,我的经验显示,这个流程的二次Bug率在20%左右,即每修改10个Bug,其中有2个可能没修改完全或者是引起新的Bug。
于是,一个改进的Bug跟踪流程出现了。
登记Bug -> 原因分析 -> 修改方案 -> 方案确认 -> 影响性分析 -> 修改 -> 修改代码确认 -> 测试 -> 测试组再测试。
这个新的流程改进时认为,修改方案没有经过确认是造成二次Bug的重要原因,并且,修改后的代码应该经过代码复查。
但是这个修改后的流程应用后的二次Bug率仍然在20%左右,甚至有抬高的迹象。
于是,一个更新的改进流程出现了。
登记Bug -> 原因分析 -> 修改方案 -> 方案确认 -> 影响性分析 -> 影响性分析确认 -> 修改 -> 修改代码确认 -> 测试用例书写 > 测试 -> 测试组再测试。
因为,过程改进人员认为,影响性分析不足是Bug没有发现的原因之一,并且,测试范围没有留下必备的文档以便确认。
但是这个修改后的流程应用以后,二次Bug率仍然没有得到改善。
于是,大家认为,不是流程的问题,是人的问题。
为了能够减少二次Bug率,一般组织都有一套Bug跟踪流程用来确保Bug修改的正确性。
下面是一个典型的Bug跟踪流程。
登记Bug -> 原因分析 -> 修改方案 -> 影响性分析 -> 修改 -> 测试 -> 测试组再测试。
这个Bug跟踪流程基本上会有一个较高的Bug率,我的经验显示,这个流程的二次Bug率在20%左右,即每修改10个Bug,其中有2个可能没修改完全或者是引起新的Bug。
于是,一个改进的Bug跟踪流程出现了。
登记Bug -> 原因分析 -> 修改方案 -> 方案确认 -> 影响性分析 -> 修改 -> 修改代码确认 -> 测试 -> 测试组再测试。
这个新的流程改进时认为,修改方案没有经过确认是造成二次Bug的重要原因,并且,修改后的代码应该经过代码复查。
但是这个修改后的流程应用后的二次Bug率仍然在20%左右,甚至有抬高的迹象。
于是,一个更新的改进流程出现了。
登记Bug -> 原因分析 -> 修改方案 -> 方案确认 -> 影响性分析 -> 影响性分析确认 -> 修改 -> 修改代码确认 -> 测试用例书写 > 测试 -> 测试组再测试。
因为,过程改进人员认为,影响性分析不足是Bug没有发现的原因之一,并且,测试范围没有留下必备的文档以便确认。
但是这个修改后的流程应用以后,二次Bug率仍然没有得到改善。
于是,大家认为,不是流程的问题,是人的问题。