协作流程优化
发布时间:2022-03-01 16:32:31    浏览次数:次  作者:来源互联网

      

初版的协作流程如图1-1所示,整个流程涉及了产品人员、UI设计人员、测试人员、开发人员和项目管理员五种角色,并设计了未开始、待内审、待评审、待UI设计、UI设计中、待开发、开发中、待产品验收、待测试、测试中、测完待发布、待数据回顾、关闭共13个项目节点,每个节点关联一个角色负责人。

图 1-1 软件项目协作流程

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

图 2-1 【爱测角】软件项目协作流程——优化版

首先,新的协作流程里增加了部分节点,例如UI设计及研发方案待评审节点、测试线上验证环节。同时,设计节点也补充了待研发方案设计的状态,开发中节点补充了测试用例设计中的状态。

其次,流程里完善了前置节点未通过情况下的流程指引,例如开发自测用例未通过的情况下节点可转回开发负责人,线上环境测试未通过时进行停止发布或回滚服务(处理方案视具体情况而定)。

再次,流程将不同角色可并行的环节进行合并,例如分别将设计、评审和验收环节合并为一个时间节点,增加多角色并行处理环节,对整体协作流程进行了简化。

为什么要设置这些流程呢?优化协作流程对我们测试人员来说有什么帮助?

(1)对于一个项目来说,项目进度的把控对于项目风险的把控极其重要,流程的设计一方面是要关注项目应该在规定的时间进入预期的项目节点,另一方面也是为了关注在对应的项目节点是由谁跟进负责,做到项目进度清晰,项目节点责任到人,这也是为什么笔者设计的流程图里各个项目节点都关联着各自的负责人。

(2)为什么要增加UI设计及研发方案评审的环境?当前或者说前些年测试领域都在推广着测试左移(测试前移),其本质思想其实就是为了让风险前置。如果没有方案评审环节,或者说这个评审环节因质疑测试人员参与的必要性而不对测试人员开放,从而引起信息不同步,其结果就是项目风险后置到了产品测试阶段,其问题修复成本也随之提高。

(3)为什么要增加自测和自测不通过转回开发环节?对于责任心比较高且质量意识比较强的研发人员来说,这个环节完全可以忽略或者是简单地走个形式流程,但是对于责任心不高且开发能力一般的的开发人员来说,这个环节是测试人员必须重点关注的。如果没有这个环节,没有提测不通过数据的数据支撑,项目延期和项目质量的风险只会是测试人员独自承担,所以需要这个环节来暴露开发的的质量风险并进行约束。