《产品质量规范》管理方案

 

问题:测试做梳理出《产品质量规范》这件事情的意义是什么呢?

解答:  首先测试作为质量的守护者,对产品质量的负责这是最基础的该做事项,但是仅凭测试人员是无法保证产品质量的,因此从最基础的出发,应从各个管理团队着手去把控产品质量的输出。很常见的事情在平时的工作中,很多情况属于被动,一旦发生问题任何人都第一反应是测试人员的问题,是测试人员不负责任没有测试到,属于漏测等等各种说法持续而来。持续的时间久了,测试人员心里很委屈,有时明明不是自己的责任还被别人怀疑加指责。因此将责任划分到各个团队,一起来守护产品质量。

           总则:梳理出质量问题出现后各团队该承担的责任与处罚,具体如何减少质量问题平分到各个团队自己去落实找出最佳的解决方案。因此如下的所有仅在说明结果和责任的划分与承担。

一、产品质量问题的定义

      【iBer产品反馈沟通群】被客户发现且进行投诉的问题

 

 二、质量问题影响

  • 客户:降低了客户的产品体验与使用,使用户无法达到自己的预期目标
  • 团队:容易被别人质疑能力不足,难以取得信任
  • 公司:客户的使用体验较差,容易流失客户,造成经济上的损失

 三、质量问题分类

  • 严重【必现】【非兼容】
    • 容易触发,一二级路径的功能性问题 
      • 无反应
      • 闪退
      • 白屏
      • 功能主流程未实现
    • 付费类bug
      • 非付费用户可使用付费功能(前提:产品有明确需求说明付费与非付费的功能划分)
      • 付费购买支付失败(微信、支付宝、信用卡)
  • /低【必现】【非兼容】
    • 显示明显的问题 
      • 样式显示
      • 数据显示错误
      • 交互体验
      •  
    • 触发条件极其苛刻,路径不容易触发
      • 闪退

四、质量问题总结

  • 严重
    • KM 上沉淀(质量问题总结财富库) 
      • 分析总结:产生质量问题的原因,思考总结和吸取经验教训,后续如何避免该同类问题的发生。
      • 必要的问题通知品控添加到checklist中,作为版本上线的必检查点
      • 周会进行分享,部门内部公开学习,避免其他人员同样的情况再次发生,尽可能减低出现质量问题
  • /
    • 分析总结:产生质量问题的原因,思考总结和吸取经验教训,后续如何避免该同类问题的发生。
    • 必要的问题通知品控添加到checklist中,作为版本上线的必检查点
    • 周会进行分享,部门内部公开学习,避免其他人员同样的情况再次发生,尽可能减低出现质量问题

 

五、质量问题责任承担

         已迭代版本为依据,按照问题严重程度来区分所承担的责任,按月统计且已直接扣款的方式执行,若同样的问题在同一个版本出现多次,扣款将以等差递增。

  • 扣款标准
    • 严重
      • 100元(以100的等差递增)
    • 中/低
      • 10元(以10的等差递增)
  • 责任的承担
    • 直属Leader
      • 监管之责(双倍扣款)
    • 责任人员
      • 直接责任人(按照扣款标准完成扣款)
    • 项目经理
      • 监督之责(与责任人员承担相同的扣款)
  • 责任的划分(代表性场景示例)
    • 研发责任(全责)
      • 版本已上线,品控未知的情况下,发生代码覆盖
    • 品控责任(全责)
      • 产品需求明确,未测试到
    • 设计责任(全责)
      • 明显的UI样式问题
    • 运营责任(全责)
      • 产品中由运营录入数据产生的数据/文案问题
    • 产品责任(全责)
      • 产品经理与开发私自沟通改需求,未同步项目经理,引起了产品的质量问题
    • 品控、研发责任(平分)
      • 线上Bug处理完之后,开发未同步品控所涉及模块,引起某些模块出现问题
    • 设计、产品责任(平分)
      • 用户提出的交互体验问题,且已影响到用户目前的使用
    • 产品、研发、品控责任(平分)
      • 同一功能多个入口,需求未说明、开发未更改、用例未涉及
  • 责任的评定
    • 直属Leader、项目经理 将依据问题的产品原因来判定责任的划分 

六、引发质量问题的原因(代表性场景示例)

  • 需求变更频繁,需求描述不清晰
  • 团队人员对产品的质量意识不足
  • 团队人员的知识储备不足,未考虑到此类问题
  • 对之前人员负责此模块的具体情况不了解
  • 项目紧急上线,时间不充分
  • 环境或数据有限,无法模拟并覆盖执行所有正常和异常的场景分支
  • 资源有限
  • 修改bug涉及的范围不确定,引起其他的bug问题出现
  • 部分人员之间沟通改需求等,未同步到其他相关人员
  • 代码覆盖

七、预防质量问题的措施(代表性场景示例)

  • 提高人员对质量的认知意识
  • 需求涉及范围、主要规则等描述清楚
  • 多沟通交流、学习,提升知识储备量
  • 充分评估时间,避免因时间紧促,验证不足发布上线
  • 代码的部分修改充分评估可能发生的影响功能点与范围,及时通知对应人员进行验证
  • 任何在初始阶段确定的工作,在后期中有任何变更,及时同步相应人员
  • 合并代码过程中,充分评估合并后可能存在的风险,及时同步相应人员沟通验证
  • 加强项目实施的过程监督

八、责任的落实

         各中心建立相应的质量把控意识,提高整体产品质量

  • 示例
    • 产品中心:产品经理深入了解用户需求等,设计简单、易懂、易用...的交互体验等
    • 设计中心:UI走查确认与原稿设计的完成率,提升交互体验
    • 研发中心:开发提高编码质量,减少合并代码中出现的代码覆盖等
    • 品控中心:品控人员减少漏测等
    • 运营部门:运营人员减少因配置产生的问题等

九、附属说明

  • 项目经理不承担责任
    • 产品上线,再次修改已上线的版本中问题,修改问题未同步项目经理,引起的质量问题
    • 交互体验问题
  • 项目经理承担责任
    • 产品上线,再次修改已上线的版本中问题,且已与项目经理沟通确认修改方案,引发的质量问题
  • 产品经理不承担责任
    • 研发与品控私自沟通新增/修改需求,未同步产品,引起质量问题

猜你喜欢

转载自www.cnblogs.com/syw20170419/p/11359168.html