改进版缺陷管理系统

后台回复「星球」，免费加入星球

阅读本文大概需要 5 分钟。

我是一个实用主义的人，所以做事经常会考虑实际的效果，带来的好处就是实用，坏处就是有时候定制化太强，但是这两方面往往都是要取个平衡。

就拿缺陷管理系统来说，其实作为测试，我们最熟悉的就是缺陷管理系统了，可是谁能说目前自己用的就是顺手的，反正我用过几个系统，都有各自的一些问题，所以一直想做个改进。

但是大家都知道，缺陷管理里面的流程流转和权限设置还是蛮复杂的，所以就迟迟没有动手。

刚好，前些时候看《重新定义公司》，里面有个观点很触动我，「开放为王」，是的，其实我们想像中的很多桎梏都是不存在的，有一些无关紧要的自然规律，我们无需强加干涉，他们都是可以按预期正常运作的。

基于此，我开始设计了新的缺陷管理系统。

首先，我的系统里面没有开发、测试、产品等角色设定，所有人可以操作所有的按钮，包括新建、解决、指派、编辑、备注、删除等。

其实加上权限设定也无非是按角色设定谁可以点击什么按钮，但其实大部分人是知道自己角色应该干什么的，那么与其做复杂的权限控制，还不如交给大家自己去决定，退一万步说，就算改了自己不应该改的状态，也并不紧要，就是统计数据的时候会有偏差，提醒一下就好了。

其次，缺陷状态也很简单，待开发处理、待测试验证、已关闭，就这三个，没了。

内部流程状态这种东西，大部分都可以通过沟通解决，大不了好好利用下备注的功能，所以没必要状态变来变去的麻烦。

当然，有些关键状态我也是有记录的，比如 reopen，我虽然没有这个状态，但是激活这个动作我是有操作记录的，所以完全可以通过记录来汇总这个数据，而不是额外增加一个状态让流程变得更复杂。

然后，缺陷类型就五个，本可规避的设计缺陷、设计缺陷、本可规避的代码问题、代码问题和其他。

这么区分主要是为了统计影响本项目质量的主要原因。

如果主要原因是「本可规避的设计缺陷」，那么类似项目以后就要加强需求评审的过程质量。

如果主要原因是「设计缺陷」，那么就要让产品考虑怎么把本次项目的经验做好积累，方便在后续项目中提前规避类似问题。

如果主要原因是「本可规避的代码问题」，那么类似项目就要增加提测准人的条件，比如更严格的代码 Review 和更详细的代码逻辑讲解等。

如果主要原因是「代码问题」，那么就要和开发沟通看看怎么把目前的问题进行沉淀，考虑增加前置阶段的检查，还是加强编码过程中的自测等等，尽量避免同样的错误在后续项目中再犯。

如果主要原因非前面四个，那就要重点看看我们的测试计划、测试策略以及测试执行的过程是否有问题了。

最后，基于个人经验，在新建缺陷时，做了一个简单的智能推荐，比如保留本产品最后一次提交缺陷的所属项目信息、指派人和抄送人信息等等，如果不是频繁的项目切换，这些信息基本都是不需要变化的，一定程度上节省了操作的便利性。

当然，通过剪切板粘贴图片这种刚需，也必须是支持的。

总之，这个系统的逻辑完全不是按照传统的缺陷管理系统来构建的，但是从目前提交的 700 多个 Bug 来看，是可以满足需求的，而从投入来看，因为大量复用了之前的系统模版，断断续续用了一周左右的时间就搞定了，所以投入并不大，物超所值。

以上，通过自己对缺陷管理系统的理解，借助开放的心态进行了简单重构，在投入不大的情况下，极大的提升了使用体验和使用后的效果，不知道你对此有何看法？欢迎留言和我讨论。

当然，如果你认可我的观点，欢迎分享文章到朋友圈 + 点个「在看」让更多人看到，谢谢。

为了感谢大家的支持，我准备了一个抽奖，在 5 月 15 号 15 点 15 分自动开奖。

感谢你的阅读、在看和转发，点我抽奖，祝你好运！

推荐阅读：

一季度总结

面试到底公平不公平？

手把手教你轻松找回忘记的密码

什么是好的测试用例

软件测试的类型