当前位置: 首页>前端>正文

Great Expectations 质量 质量bypass

我想表达的质量的分级,并不是质量分级管理策略,而且在面对不同规模的质量团队的时候,跟踪质量采取的策略不一样。

  1. 作为部门体系建设者,40-100人规模,迭代中的产品很多的情况下
  • 质量数据,质量数据分为几个方面,一个是prod bug,一个是prod bug逃逸率,比较分为,横向比较和纵向比较,横向是不同的时间段,自己和自己比;纵向,是同一个时间段,部门内部产品对比。比较的意义在于,形成探讨和争议的氛围,从而激起大家的质量意识。并通过此,制定合理的质量目标。付出行动。我觉得我的团队在此上做的并不好,质量数据放在那里就在那里了,没有起到应有的效果。落实还是需要高层支持的
  • prod bug纳入问题管理,如果想以点带线带面,将问题分清楚,那么需要prod bug的5why分析法,分析到组织架构和质量体系优化层面
  • 关注成本和效率。时间和人员都是企业的资源,缩短质量反馈时间,控制人员成本,如何去做,需要全局评估
  • 注意:不可以一个指标去评价某个产品的质量,需要多个质量数据协助分析

  2.  一系列有关联性的产品的质量负责人(10-20人)

  • 有些质量,是可以通过质量数据的综合分析进行获取,有些是通过质量数据察觉不到的。比如,开发人员未按照架构设计去实现产品,因为产品需求的紧急性,在存储数据方面,尤其在跨系统集成上,就近存储从而避免和其他团队的沟通;又比如前后端设计上, 业务逻辑放在前端做处理。这些是JIRA,或则bug中无法察觉的点,需要深入技术细节才能发现。这就需要质量负责人敏锐的嗅觉,产品意识,架构思维同时又能深入一线
  • 问题定位,同问题管理,一个生产事故和prod bug往往都是质量体系不完善的很好的切入点。我当前发现的质量问题,很多根本原因都是组织架构不合理导致,比如,产品人员,来自不同的部分,彼此产品有紧密关联的情况下,大家会从自己最方便的角度考虑,而缺乏全盘的产品架构的设计;比如,同一类型的产品,技术架构分属于不同的团队,技术缺乏统筹此类的问题

  3. 一线测试人员

  • 测试覆盖率
  • 有无合理的测试策略进行全部覆盖并且能快速给出反馈
  • 能否基于真正用户的角度去考虑,测试用户产品。这点很多测试人员十分缺失,我们更多追求测试的花样性,而缺乏对于产品价值的认真思考。我们有出现过为了追求新技术的应用,影响用户基础功能的情况

 


https://www.xamrdz.com/web/25e1933098.html

相关文章: