在工作中,因为PM、研发、测试三者对BUG的理解不一致,导致沟通过程中造成一些不必要的沟通成本。

今天花点时间,梳理一下我对BUG的理解,尽可能做到简洁明了,通俗易懂。

一般来说,研发人员理解的Bug的是指因为编码或逻辑处理错误导致的非期望结果,包括对边界值、异常等考虑步骤、覆盖不全、处理不足等导致的问题。

对这一类Bug,可以细分为:

  • 阻塞性Bug,即,操作流程无法正常显示、继续和结束,不包括系统对异常情况的处理。
  • 功能性Bug,即,操作能够正常结束,但因实现原因,导致出现非正常的结果、错误等。
  • 显示类Bug,即,操作能够正常结束,但交互、视觉、显示等与UE视觉稿不一致,包括文案、颜色、布局、显示位置等。

对以上因编码实现原因导致的Bug,对应责任人为研发人员(包括前端人员),必要时经PM确认。

但从产品角度,所有与原始需求预期不一致的最终实现和效果,都可以定义为Bug。

原始需求包括:

  • 需求文档声明和指定的需求、功能、文案、提示等
  • 交互设计稿指定的操作步骤、流程和结果指向
  • 视觉设计稿指定的图片、文本、布局、显示位置、尺寸等
  • 系统设计文档包括接口文档指定的数据结构、数据类型等输入、输出

所以,除以上Bug外,需增加两类Bug:

  • 需求型Bug,即,代码实现已按预期完成,但因需求遗漏或分析不足等原因,未达成产品预期功能目标,并最终表现为产品或功能缺陷。
  • 交互型Bug,即,代码实现已按预期完成,但因交互或视觉设计原因,导致的交互和视觉等没有完成MRD预期要求等。

以上Bug的责任人分别为PM和UE,修复方案由研发人员经必要评审、评估后负责实现。

除Bug外,测试过程中测试人员可能会发现还需要补充或摘出除Bug以外的产品缺陷或设计缺陷,对这部分定义如下:

  • 待完善(Improvement):功能能够正常完成,交互文案等符合设计稿要求,但设计、交互、文案等繁琐、有歧义,可以进一步完善的地方。
  • 待加强(Enhancement):功能能够正常完成,且能够满足用户需求,但可以有更好的实现和解决的方案。
  • 新功能(FeatureRequested):不影响用户理解、使用和操作,术语产品新功能的需求。

原本是给公司写的,今天先发在博客上,目的只有一个,再也不要因为BUG提给谁、提什么类型的BUG这些破逼事儿烦我了。

晚安。

仅有一条评论

  1. fdfdsfadmin23123123132

    fdfd

添加新评论