继上一回合日报与工时融合集中式填报的创新实现后，本篇我们来讲一讲流程驱动缺陷管理的创新实现。
背景
肯定会有人说，不就缺陷管理嘛！几个状态完事，爱咋整就咋整，没必要搞流程化，搞流程就是把简单事情复杂化。
正是基于上述看法，市面上其他的研发管理软件中的缺陷管理，并不支持流程驱动。虽然有些有所谓的工作流配置，但仅仅是页面显示及显示顺序的定义，如从 A 页面跳到 B 页面再到 C 页面,以及每个页面上显示什么属性等；还有另一种常见的就是可以定义缺陷的状态，以及这些状态的演化关系，这两种不是真正意义上的流程驱动，为什么这样说呢？
对此我们有不同看法，首先，标准的流程一定是包含业务角色的参与者和业务状态的演化；其次，通常缺陷管理中只有这几个状态：激活、已解决、已关闭，这很难反映更精细化的业务需要。比如已关闭，是修改后真正的关闭，还是改不了遗留下来的关闭等等，再比如开发和测试对缺陷的有不同意见时，不能通过状态一目了然表达出来，只能看备注等信息，再比如项目参与人员多，测试人员没法知道提交给哪个开发人员修改时，转给谁来分配；再比如开发想把某个缺陷延迟到下版本修改，应设置为什么状态以及由谁来确认可以延迟修改。
如上所述，缺陷管理确实需要工作流，但是采用通常的工作流的实现方式，不但工作流的配置有门槛，且缺陷流转过程中的交互可能也会变得复杂。工作流是刚需，那如何在不增加使用者负担的基础上，让流程驱动的缺陷管理简单易用呢？
Codes 产品团队始终以用户为中心，采用化繁为简的方式解决用户痛点。要想解决工作流的复杂度问题，只能另辟蹊跷，且看下述需求分析过程。
1、需求分析过程如下：
引入工作流，配置上就会有这两个问题：一，用户要自己会配置工作流，二，要会设计一个合理的缺陷管理的工作流，这极大增加了配置门槛。使用上也会有问题：缺陷的流转控制如何让用户无感知，要不然体验就很差，比如过多的缺陷状态会让用户流转缺陷时晕头转向。我们借用模板的思路来解决配置问题：系统完全可以定义一个最全的流程，然后用户在模板流程上进行裁剪，裁剪时只要勾选不同的流程节点，然后在不同节点上再分配不同的参与人员即可；缺陷的状态转化大致的实现思路：不同的流节点对应不同的状态，然后由流程引擎来控制在什么节点上什么参与者可以演化为什么状态，然后再按状态向上或向下流转；页面交互时，使用人员不需要关注有什么状态，以及能转化为什么状态，系统自动控制，使用人员只需要选好想要转换的状态，然后再根据所选择的状态引导他选择下一流程节点的处理人即可。
看文字理解起来太累，下面有图有真相，来看看具体的功能实现。
2、功能实现之流程配置
如下图所示，一个完整的流程从 1 提交问题、2 到测试交叉、3 到分析问题、4 到分配问题、5 到修改问题、6 到开发互验、7 到分歧仲裁、8 测试确认。这流程可以说是全网最全的一个缺陷流转流程，图中框起来的为必选流程，其他为可选，流程可实时修改。Codes 缺陷处理流程配置非常简单：在下图中 1、勾选要开启的流程节点 2、指定所勾选流程节点上的相关处理人员。
测试过程中可以实时调整测试流程，取消某个可选流程时，系统会把停留在该节点上未处理的缺陷自动流转到下一流程。
3、功能实现之缺陷流转
相关人员处理缺陷时，不用关心缺陷有多少种状态，缺陷控制引擎会自动根据测试流程，缺陷当前状态及处理人员在项目测试流程中所处的的流程节点自动算出来，当前可转换为什么状态以及选了不同状态后谁作为下一处理人。在缺陷管理列表中，点击某个缺陷的状态进入缺陷流转处理。下面用几个示例来说明。
开发处理缺陷示例
上图中为在修改问题节点上的开发人员处理缺陷时，可演化的状态示例：如设置为"费解/需提供更多信息"或“非错 “时就自动打回到测试人员，如设置为” 挂起/不计划修改" 或 ” 挂起/下版本修改 “时就流转到仲裁人处，如设置为” 已改 “或” 已改/同步到测试环境 “，就流转到测试确认环节，由测试确认后再关闭。
测试提交缺陷示例
如测试提交后下一流程为修改问题，则新提交的问题为 “待改”状态；如下一流程为分配流程就” 分配 “状态并转分配人来处理；如下一流程为分析流程就是” 分析 “状态并转分析人来处理；如下一流程为测试互验，就是” 待置 “状态并转互验人来处理，且如互验人认为“待置” 的缺陷，描述有问题，可以设置为“修正/描述不当”，或直接“撤销”了。
测试处理开发设置为非错的示例
这时测试如认可非错的理由，可以” 撤销 “，不认可选择” 分歧 “后就转到仲裁人那，由仲裁人来裁决。
仲裁人仲载” 分歧 “的示例
仲裁人如认可测试人员的理由，可以改为” 待改 “，再转开发人员修改，也可认同开发人员，认为这确实不是问题，选” 撤销 “即可，如果认为确实是一个问题，但是可以不改，就选择” 关闭/撤销 “并写明理由，如这需要另外的仲裁人来仲裁，选择” 仲裁 “并选择对应的仲裁人也是可以的。
不再一一示例了，总之 Codes 的流程引擎会根据当前缺陷的状态，及所处的流程来控制可转化为的新状态，然后根据所选的新状态，选择下一处理流程的处理人。
4、缺陷流转用时及时效性分析
快上线前，缺陷一般要求日决，我们要能查看到各环节用时信息。Codes 会记录各节点上的用时信息，如下图所示：
Codes 对于不同等级，不同严重程度的缺陷可以设置不同的整体用时，只要缺陷的从发现到关闭之间的用时超过了设置的标准用时，就认为时效性不足，不达标。下图为达标标准设置：
下图为时效性分析示例数据
还可下钻到人
5、功能实现之缺陷状态演化及不同流程使用场景说明
5.1、缺陷状态及演化
Codes 中共有 27 个缺陷状态，听起来很吓人，但是使用的时候一点不吓人，也不需要 “硬背” 这些状态及它们之间如何转化，因为这 27 个状态分别对应到不同的流程上，分散下来实际多少状态了，且当前状态能转化为什么状态要依懒下一流程是什么来决定，参见第 3 节所述及示例。设计这么多状态，就是为了能通过状态就能一目了然了解缺陷的实际情况，不需要进入缺陷详情中查看明细才能明白。因篇幅关系，就不一一列出各流程节点上有什么状态，以及具体状态间的演化逻辑，下面加粗的为具体 27 个状态：
“待置”、“修正/描述不当”、“重复”、“无效”、“撤销”、“不再现/需提供更多信息”、“待改/再现”、“待改/不再现”、“待改/未解决”、“待改”、“修改中/持续跟踪”、“费解/需提供更多信息”、“分歧”、“已改”、“已改/同步到测试环境”、“非错”、“关闭/已解决”、“关闭/不再现”、“关闭/撤销”、“关闭/遗留”、“重分配”、“挂起/不计划修改”、“挂起/下版本修改”、“待改/下版本修改”、“分析”、“分配”、“交叉验证”
下图中框起来的部分，记录了 17 个常用的状态使用场景。
5.2、不同流程使用场景说明
在 Codes 中，对于每个项目，可以从 Codes 提供的流程中选取部分或全部流程作为当前项目的测试流程，测试过程中可以实时调整测试流程，取消某个可选流程时，系统会把停留在该节点上未处理的缺陷自动流转到下一流程。
* 提交问题：必选流程，人员主要为测试人员，不在这一流程节点上的人员也可填报缺陷，但不在这一流程节上的人员不能关闭缺陷。
测试互验：可选流程，带新人时，再如何强调写缺陷的要求及规范，新人记不住，可让资深测试工程师或是导师来做为新人把关，通过测试互验流程，手把指出新人写的缺陷存在的问题，带一两个月新人就能快速成长，使新人能编写高质量的缺陷；也可以在开发人员处理缺陷前，测试人员内部对新提交的缺陷进行 review，省去了缺陷描述带来的理解上的差异，或是其他人在复现时带来的沟通成本，如果团队是分布式的沟通成本非常高。
分析问题： 可选流程，分析缺陷产生的原因，估算修复缺陷需要的时间及期限，一般为技术经理、系统分析师来做分析工作。
分配问题： 可选流程，当团队较大或项目太大，一个模块就是一个子系统，测试人员搞不清所提的缺陷提交给哪个开发人员来修改时，就要开启分配流程，测试人员只要提交到分配人即可；一般分配人应该为研发经理、研发组长等，可以有多个分配人。Codes 也支持按模块预分配，就不需要分配流程。
* 修改问题： 必选流程，此为修复缺陷的环节，设置的人员是研发人员。
开发互检： 此为研发工程师修改完缺陷后，互相之间的交叉检查。设置的人员是研发人员。
* 分歧仲裁： 必选流程,当开发认为不是问题，并设置为 “非错” 状态，但测试坚持认为是问题，测试就可以设置为 “分歧”，就转到仲裁人处进行仲裁；研发工程师要求缺陷延期修改，或不计划修改某个缺陷，或让缺陷遗留时，由仲裁人进行裁决。一般仲裁人为研发经理、产品经理等。
* 测试确认： 必选流程，且不需要再指定确认人，复用提交问题环节的测试人员，何何人都可提交缺陷，但只有测试人员才能确认缺陷是否可以关闭。
最后打个总结：
流程驱动的缺陷管理就是：” 因地制宜”， 告别一刀切，可按需实时调整测试流程，以反映不同管控目的；不同流程节点对应不同的缺陷状态，更能反映项目实况，并根据流程推动缺陷状态的演化。创新不是为了玩新奇，是为了解决问题，Codes 上述实现方式确实化繁为简。下一次我们来聊聊 Codes 0 代码接口自动化测试，也是很酷的功能，欲知后事如何且看下回分解。匠心打磨，持续创新是 Codes 的产品基因。
有客官可能不知道 Codes 是什么，小 C 在这里最后补一句：
Codes 重新定义 SaaS 模式的一站式研发管理平台
云端认证 + 程序及数据本地安装 + 不限功能 + 30 人免费
扫码查看 Codes 详细介绍
