在本文之前，笔者曾分享过一篇关于质量保障流程的文章《漫谈项目质量保障——协作流程》，文章简述了笔者参与的项目协作流程，同时对流程中一些不同寻常的协作节点进行阐述。由于多种原因限制，之前分享的流程存在一定的不完整性，所以本文将继续分享《漫谈项目质量保障——协作流程》优化后的版本。
  初版的协作流程如图 1-1 所示，整个流程涉及了产品人员、UI 设计人员、测试人员、开发人员和项目管理员五种角色，并设计了未开始、待内审、待评审、待 UI 设计、UI 设计中、待开发、开发中、待产品验收、待测试、测试中、测完待发布、待数据回顾、关闭共 13 个项目节点，每个节点关联一个角色负责人。
      
            图 1-1【爱测角】软件项目协作流程

  由于协作平台功能的局限性，部分协作流程节点无法配置多角色并行处理，初版设计存在一定的遗漏和冗余。如果排除协作平台的局限性，更理想的协作流程应该是怎样的呢？如图 2-1 所示，优化后的流程依然是 13 个项目节点，但是节点和节点内容已经有了不少的变化。那优化后的协作流程与前一版本有哪些差异呢？
    
         图 2-1【爱测角】软件项目协作流程——优化版

  首先，新的协作流程里增加了部分节点，例如 UI 设计及研发方案待评审节点、测试线上验证环节。同时，设计节点也补充了待研发方案设计的状态，开发中节点补充了测试用例设计中的状态。
  其次，流程里完善了前置节点未通过情况下的流程指引，例如开发自测用例未通过的情况下节点可转回开发负责人，线上环境测试未通过时进行停止发布或回滚服务（处理方案视具体情况而定）。
  再次，流程将不同角色可并行的环节进行合并，例如分别将设计、评审和验收环节合并为一个时间节点，增加多角色并行处理环节，对整体协作流程进行了简化。

  为什么要设置这些流程呢？优化协作流程对我们测试人员来说有什么帮助？
（1）对于一个项目来说，项目进度的把控对于项目风险的把控极其重要，流程的设计一方面是要关注项目应该在规定的时间进入预期的项目节点，另一方面也是为了关注在对应的项目节点是由谁跟进负责，做到项目进度清晰，项目节点责任到人，这也是为什么笔者设计的流程图里各个项目节点都关联着各自的负责人。
（2）为什么要增加 UI 设计及研发方案评审的环境？当前或者说前些年测试领域都在推广着测试左移（测试前移），其本质思想其实就是为了让风险前置。如果没有方案评审环节，或者说这个评审环节因质疑测试人员参与的必要性而不对测试人员开放，从而引起信息不同步，其结果就是项目风险后置到了产品测试阶段，其问题修复成本也随之提高。
（3）为什么要增加自测和自测不通过转回开发环节？对于责任心比较高且质量意识比较强的研发人员来说，这个环节完全可以忽略或者是简单地走个形式流程，但是对于责任心不高且开发能力一般的的开发人员来说，这个环节是测试人员必须重点关注的。如果没有这个环节，没有提测不通过数据的数据支撑，项目延期和项目质量的风险只会是测试人员独自承担，所以需要这个环节来暴露开发的的质量风险并进行约束。

  本文主要分享了优化后的项目流程以及两个版本流程的差异，并分享了部分流程优化的思路和优化的缘由。总结来说，项目协作已经是一个比较复杂的过程，而项目协作管理只是项目质量管控中的一小部分。因此，对于测试工程师或者 QA 来说，想要把控好软件项目的质量，不仅仅需要关注眼前的 bug，还需要关注协作流程中无形的 bug……

相关引文：《漫谈项目质量保障——协作流程》

原文地址：《漫谈项目质量保障——协作流程优化》
作者：Chaofan