美文网首页
实操手册 - BUG

实操手册 - BUG

作者: CharLong | 来源:发表于2017-01-12 12:20 被阅读0次
    It's not a bug. It's a feature!

    对,这一期要说BUG,跟我读“八-阿-哥”。


    BUG的定义:本意是臭虫、缺陷、损坏、犯贫、窃听器、小虫等意思。现在人们将在电脑系统或程序中,隐藏着的一些未被发现的缺陷或问题统称为bug(漏洞)。

    在实际的产品设计工作过程中,总会遇到大量的bug,有些可以解有些不能,不能的那部分很可能就流转到了产品人员手中去评估。

    目前我们的流程是:

    1. QA发现bug-》RD调研bug-》能解的bug解决了-》QA验证是否修复完成,未完成则打回。

    2. QA发现bug-》RD调研bug-》不能解的bug进行多方评估(多方至少包含PD、QA、RD,如果和OP、UE相关则要一起评估)-》评估下个版本修复、推动外部修复还是影响不大直接降级,如果又要修复、又有较多工作量(如超过了1人天会影响排期),则要看是否加班、延期等方式解决。


    对于是否要修复,从以下几个点去判断,数值可以自己摸索、调整:

    1. 严重程度:崩溃、内容缺失、功能不可用是最严重的,只要必现就一定修复;低概率复现且低频率使用在灰度阶段可放行,正式上线还是要修复;上线除非是不可修复,其他情况下还是要修复掉。

    2. 复现概率:高复现概率的都是好bug,能够比较稳定找到问题原因;稳定复现则是高概率,不稳定复现,如10%的复现概率以下,则是低概率。

    3. 使用频率:如果一个功能低于了1%用户使用,可以认为是低频使用的。如果是核心功能、本期主打功能,自动认定为高使用频率。

    通过这三点,个人的判断就成为(&&代表且、||代表或关系):

    1. 严重&&(高复现||高使用),一定灰度前修复。

    2. 严重&&低复现&&低使用,可灰度测试,正式上线前一定修复。

    3. 不严重&&(高复现||高使用),灰度前修复。

    4. 不严重&&低复现&&低使用,可尽量修复,无时间或者有外部依赖,流转版本或者降级不修复。

    简单来说,严重的发版前一定修复,高复现或高使用的一定灰度前修复。我们的判断应该是基于严重程度、战略目标、用户影响面来进行的。


    BUG与feature

    实际的工作中,BUG和feature的界限其实没那么清晰,可以自己建立一套标准。涉及到新的功能开发、之前需求文档未能描述的部分,都定义为feature,而BUG是之前按照文档的预期应当如何却未能如何。所以我们要求PD写清楚分支逻辑后,与其他角色讨论,由QA完成test case的编写。

    也可以唯心的说,PD在设计需求时候,在和RD、QA沟通后未能考虑到的逻辑分支、视觉样式,导致了严重的功能异常,是属于大家的经验不足,这种算bug;而需求设计时,PD和RD、QA沟通不足导致了功能异常,需要增加更改,则属于PD的责任,这种需要新增加需求解决掉的,就是feature了。

    比较常见的情况,更多是PD、UE的思考不足,在产品review的阶段发现不符合预期,以bug的名义加了feature,这种情况其实不利于团队和谐。

    出现了纰漏应该用于承认,并承认后果,自己挖的坑是要自己填上,而非扔个bug就让人家加班去改了,这是明显在给自己减分的行为。由于PD自己的问题产生的需求变更、feature增加,都应该主动承担,找解决方案,例如协调QA人力、延长排期或者加班解决,在不同阶段的解决方式不同,开发前期协调即可,如果排期不死而工作量大就应该延长排期,如果排期已经明确只能陪伴跟随解决,请RD、QA吃鸡翅跪舔吧。

    相关文章

      网友评论

          本文标题:实操手册 - BUG

          本文链接:https://www.haomeiwen.com/subject/emudbttx.html