转载:https://www.cnblogs.com/imyalost/p/16560084.html

前几天在技术交流群有同学问到:“需求不明确&测试时间不足,经常加班,交付质量也不太好,该如何处理”?

群里其他同学很热心的给出了分析和建议,比如:

  1. 评估是否是技术问题,否则就是测试策略问题;
  2. 调整测试活动开展策略,测试左移提前介入测试;
  3. Deadline Driver Dev,学会自我管理和项目管理;

这些建议都能很好的解决我们在项目中开展测试活动时遇到的问题,但我有了新的思考:测试需要做项目管理吗?

如果做好质量保障工作需要项目管理能力为辅助,那么哪些项目管理能力,需要我去学习和实践?

结合工作实践以及群里各位同学的建议,我得出的结论一句话概括就是:

事前做好风险评估,事中做好进度把控,持续开展复盘改进,保障预期交付目标

示意流程图如下:

 

 

 

事前风险评估

其实在日常的工作中,风险评估这件事我们一直在做,比如:需求评审、技术方案评审、测试用例评审,本质上都是对要开展的项目进行前置的风险评估,判断是否有设计缺陷、技术缺陷等。

我们设计测试用例,也是为了覆盖尽可能多的场景,避免遗漏导致的异常问题逃逸到线上环境,对业务正常开展造成不良影响。

但这些本质上还是从技术的角度出发去评估,从项目整体的角度出发,我们还应该考虑如下几点:

  1. 工时评估是否合理;
  2. 人力时间资源是否足够;
  3. 项目目标设定是否合理;
  4. 项目推进方式是否不合理;

 

事中进度把控

项目启动后,一般会按照不同团队和角色分工,项目管理方面也会设定交付时间,比如设定阶段性的小目标,或者交付进度里程碑,来确保整体进度可控。

那么测试同学应该如何把控进度呢?我觉得可以从如下几点入手:

  1. 阶段性交付时间;
  2. 阶段性交付质量;
  3. 变更带来的风险;

首先判断是否是按照预期的交付时间交付了应有产出物,比如是否按时提测;

其次判断本阶段提测的产出物是否满足预期设定的要求,比如冒烟测试是否通过;

最后判断如果需求或技术方案变更,变更带来的时间/人力成本和影响范围是否会影响最终项目交付质量;

其实到这里大家会发现,在项目进行阶段,风险评估也是存在的。

或者说,项目管理和推进的过程,本身就是不断的评估和选择的过程。

 

持续复盘改进

我在前面的文章《复盘归因,提高交付质量的秘诀》中详细介绍过如何开展复盘,以及复盘对质量和效率带来的提升。

复盘是一个长期持续性的过程,并不是单次行动。复盘需要持续跟进改进项的完成情况,并不是改进完成就束之高阁。

持续复盘改进,大概有如下几个步骤:

  1. 对不同阶段的过程及产出物进行复盘评估;
  2. 找到做的不好的地方或者不合理的手段方式;
  3. 评估它的操作和背后的原因以及当时的解决方案;
  4. 思考问题:怎么做才能让过程和交付结果变得更好;
  5. 将更好的方式进行归纳总结并将其融入交付整个生命周期;
  6. 推广落地实践并进行度量评估,验证其是否有效,并不断复盘归因;

 

保障交付目标

软件测试工作的本质是什么?

我觉得在当下的工作实践中,依然是质量可控→提高效率→问题收敛

从项目管理的角度来说,保障项目按时高质量交付,依然是项目的最核心目标。

无论我们采用何种流程规范,技术体系或者协作机制,项目管理的最核心内容,可以拆解为如下几点:

  1. 工具:利用技术体系提高过程效率;
  2. 方法:通过流程规范约束执行过程;
  3. 策略:合理拆解目标保障目标达成;
  4. 管理:风险前置+复盘归因+高效协同+客观决策;

原文地址:http://www.cnblogs.com/ceshi2016/p/16860908.html

1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长! 2. 分享目的仅供大家学习和交流,请务用于商业用途! 3. 如果你也有好源码或者教程,可以到用户中心发布,分享有积分奖励和额外收入! 4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解! 5. 如有链接无法下载、失效或广告,请联系管理员处理! 6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需! 7. 如遇到加密压缩包,默认解压密码为"gltf",如遇到无法解压的请联系管理员! 8. 因为资源和程序源码均为可复制品,所以不支持任何理由的退款兑现,请斟酌后支付下载 声明:如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性