本篇为【从零开始学产品】系列课第1章第3节
欢迎到公众号菜单栏，获取产品经理课程更多资料
“从开始到死亡，这是世间万物的宿命吗？”
“是的，连Bug都如此。”
--摘自【修真神界】第三千六百五十一章 为了女神写Bug
（本书预计在2035年出版）
一 什么是BUG的生命周期
世界上本来没有Bug，程序员多了，
就创造出来了Bug了.程序员为什么要创建出Bug呢?
是为了要修复它们.
噢,那程序们修复了Bug没?
当然,他们不但修复了Bug,还写出来了更多的Bug所以一个Bug到底是怎么产生的呢?
是被【用户】或者是【测试】或者是【老板】首先发现的
当然,程序员也会发现Bug,但是他们往往在告诉你们之前就修复了它.
Bug其实一直都在,只是谁先发现而已.
而我们讲的生命周期,是指记录到我们的Bug管理系统中.
通常是指从记录那一天起,我们认为Bug是被创建了(但他们其实早就存在了).
而生命周期,就是指他们存在多久,中间会经历哪些状态,最后的归宿是什么
(并不是每一个Bug都会被修复).
所以,生命周期就是指在Bug管理工具中,我们记录下来的一个Bug被创建,指派,修复,复查,关闭的过程.
生命周期就是要讲清楚:
Bug应该有哪些状态,分别是由谁去触发,参与的角色又是谁.
但是,通常情况下,Bug管理工具和Bug的真正状态并不一致.
就像刚刚说到的,我们只是在Bug管理工具上新建了Bug,而实际上Bug可能存在很久了.
就好像,我只是开口说出来喜欢你.
而在你知道我喜欢你之前,你并不知道我喜欢你多久啦~
BUG的状态
我们尽可能的让Bug管理工具和Bug的真实状态一致,所以一般也是用Bug管理工具上的状态来代替真的Bug状态.
知道Bug生命周期,对产品经理和测试人员,和开发人员非常重要,这是用来规范和约束测试团队,研发团队的重要流程.
通常,Bug的生命周期分成如下几个了阶段
新建
指派
接受
修复
关闭
这是一个简单的Bug生命周期图
也是一个非常理想的图.
但实际情况不是这样的~~~
让我们接下来,依次去看一下每一个节点是怎么样的.
二 新建一个BUG
提一个Bug简单么?
上次我们提到了测试用例,有说到,测试用例要有前置条件.
其实,和测试用例的预期结果不一致的,都可以被称之为Bug.
但理论上,你是不可能把所有的测试用例都写完的.
一个原因是:
总有超出你预料之外的因素,或者是神操作出现.
另一个原因:
成本的问题,没必要把所有的测试用例都写清楚.
(没点Bug上线,用户会不习惯的,逃).
提BUG重要原则之一
所以,记录Bug的第一个重要原则就是:
说出运行环境和操作步骤,并配上截图.
1 运行环境
2 操作步骤
3 截图运行环境通常是指:
操作系统,浏览器版本,Android和IOS版本
厂商,当前运行的软件版本,正式和测试环境等.
操作步骤简要说明如下:
1.打开房门准备入洞房
2.掀开红盖头,
3.发现没有美娇娘,反而是一个好儿郎错误截图
期待结果
提BUG重要原则之二
第二个重要原则就是,说明是偶现还是必现.
这一点很重要,坦诚的讲,如果是只是偶尔一次遇到
而经常会遇到
我..也不是不能接受啊!
这叫偶现,对于程序员来讲,就代表着要追查的难度增加.
而必现,指的是至尊宝每次进洞房,都遇到的是如花.
(那他早把月光宝盒撸烂了吧.)
1 偶现
2 必现提BUG重要原则之三
第三个重要原则是,给出产生Bug的数据
很多时候,Bug并不是每一个人都会遇到的,而是只有特定的场景下,才会出问题.
只有某一个人才会出问题.
我们之前做公众号的时候,就发现一个妹子一点就错,后来才发现是妹子的名字有emoji表情符出错.
所以在提Bug的时候,
要记着把测试时出现的数据提供出来,
方便程序员去拿这个数据复查.提BUG的角色
最后说到,提Bug的角色,一般都是QA.
所以,无论是客户,老板,还是研发团队自己,或者是用户,
发现了bug,请直接反馈给我们的QA,
由QA统一录入,QA才能知道,这些Bug是不是真实存在,
是不是和已有的Bug重复,
是不是开发人员已经在修复 ,
是不是使用方法不对,
是不是和需求一致.更新过的角色图是这样的
三 指派
修复BUG
好了,我们已经完成生bug,呃,提Bug最重要的步骤.
现在问题只有一个啦,谁来修复?
喂,喂,你们别走啊,这个Bug谁修复啊?
....所以,指派功能很重要.
QA需要提出Bug之后,把Bug指派给某一个倒霉鬼,啊,勇于承担责任的人.
通常,研发团队都会有指定的负责模块.
如果你知道是哪一个人在维护哪一个模块,你可以直接把Bug指派给他.
而大多数的时候呢,你不知道谁在负责什么事,也不知道这个问题可能属于哪一个人,怎么办?
不要试图去弄清楚谁应该修复这个Bug,这不是你的职责.
前端会说,这是后端的,你指给后端吧.
后端会说,这是前端的,你指给前端吧.
前端会说,这是PM的需求,你指PM确认吧.
PM会说:???Bug已经创建出来了,找不到人接手
(是不是好像宝宝生出来了,却没人承认是自己的孩子).
最好的方式就是指给研发团队的小组Leader.
不管是前端还是后端,还是App端,或者是别的.
你能分清的,你就分给明确的负责人,你不知道是谁的.
你直接指给小组负责人,他可以很快的判断出来,这个Bug应该谁修复,
他如果自己都不知道谁应该为此负责,就自己写呗.流转与确认
指派这个环节,最关键的地方就在于,并不是只有一次.
通常,在Bug的确认过程之前,会流转好几次,在Bug的修复过程中,有可能会在不同的人手里流转好几次.
这是Bug修复的正常状态.
但是往往会发现一种情况,就是有人认为不是自己的Bug,又没有及时把Bug扔出去.
最终导致的就是,Bug卡在他那里,动不了.
因此,我们需要设置一个Bug的确认时间,还记得我们上节讲的Bug的级别没有?
Major级别以上的Bug,都要求在2个小时之内做处理,
要么流转,要么接受.
Normal以下不超过2天.这是需要大家按照自己的约定去调整的过程.
这是一个很关键也是很容易被忽视的过程.
指派可能会是以下几种原因:
1.来自QA的指派
2.确认不是自己的问题,指派给下一个可能的人
3.属于自己的问题已解决,但是还是需要其他人做下一步的处理.指派的时候需要带上描述,比如说:
"亲,我这边测试出来的结果是这样的,没有错,你看一下,是不是你那边可能出问题了?"
毕竟指派可能就是甩锅啊.
指派是Bug流转的重要环节,不要让自己成为流程中的卡点.
那么在图上,应该是这样的.
四 确认
确认与回应
其实这个可以讲的简单一点.确切的来说:
指派是一个动作,新建的时候,Bug的状态是未分配.
啊,之前讲错了我好难过.
但是算了,我们现在纠正过来~~
正确的状态应该是这样的:
这才完美~
[新建],[指派]这些是动作.
[新建]之后,是未分配的状态.
通过[指派]的动作,变成已接受.所以.当指派完之后呢.要先接受,表示好了,这个事我安排上了.
跟着就是可能会继续指派.
这个时候不会更改已接受的状态,不过Bug在谁手里,都是在这种已接受的状态.
这个状态没什么可讲的.
但是刚刚突然想到了,我原本是不想在这个时候提起的.
就是这个时候,研发团队并不是只有接受的权利,实际上,还提供了其他可选择的几种状态.
无法复现
设计如此
推迟修复
重复Bug这是程序员们回应QA的最好的武器,特别是无法复现.
当然,你要确定是真的无法复现,
不然测试小妹妹那边就是不好,只是研发团队可用,是没有用处的.
设计如此是在嘲笑QA的智商.
推迟修复就是做排期,我知道应该修复但是我就是不想修复的代名词.
重复Bug,就是在说你眼瞎么我已经在处理一样的Bug了.所以,图应该是这样的.
五 已修复
谁优先
程序员修复Bug,是要有优先级的.
正常来讲,我们推荐两种Bug的处理方式.
第一种.Major级别以上的Bug,立刻修复,停掉手里的事情.
第二种,Major级别以下的Bug,
跟着下一期的版本正常修复,或者是单独发布一些小版本.这里的关键点在于:
第一要对Bug区分优先级.
第二,要处理好修复Bug和当前所完成的项目之间的冲突.
第三,所有的Bug修复产生的对当前项目的影响,研发团队自己承担.那么,什么时候应该标成已修复的状态呢?
是在开发团队在开发环境验证之后.
关于开发环境,测试环境和线上环境的区分,我们会在下一节的课里讲清楚.
推荐的Bug变更成已修复的流程是:
开发人员在开发环境去给QA演示Bug已经修复完成了,
QA确认后,才去更改状态.误区
注意几个常见的误区:
1.不要未修改状态就发布到测试环境
2.不要未演示就修改状态这两点如果能够把握好,对Bug的修复流程就会好很多.
六 已关闭
完成
那么,当开发人员确定是修复完成了.什么时候应该是改成已关闭的状态呢?
Bug会有在两个环境发生,一个是测试环境,一个是线上环境.
测试环境的Bug,就在测试环境验证完成.
线上环境的Bug,第一时间看在测试环境能否重现,
如果可以重现,就在测试环境完成.如果不能重现,就在线上完成.验证
如果说验证的时候,不通过,怎么办呢?
改成Reopen,重新打开
(我不确定是否只在Bug关闭的时候才应该打开它
但是一个Reopen的状态就够了,它和未分配其实是一样的,只是用来标记一下
这是一个二婚).
七 小结
这一节重点讲了Bug的生命周期.
以[未分配]为开始,以[已关闭]为结束.
像不像爱情?
以未婚而开始,以接受命运的指派而改变,
寻找真命天子,往返奔波,最终确认婚姻的殿堂,
接受生活的验证,要么白头到老,要么重归单身.这就是Bug的生命周期,也是爱情的生命周期.
可是存在没有Bug的人生么?
可是存在没有Bug的爱情么?
在爱情的世界里,两个人的分歧,到底是Major级别,还是Normal级别,又该用怎么样的方式来处理?
谁提出来的Bug,谁又能够规定必须要在多久的时间内修复?
线上环境算是正式的婚姻么?
测试环境算是谈恋爱么?
开发环境算暗恋或者是恋爱之前的懵懂?
谁才是真正解决你的爱情的那个人?
谁才是能够和你明确你的爱情不属于她的人?
如果你知道,爱情是有生命的.
那么你就应该明白,Bug是同样有生命的.
现在只剩下了一个问题.
我问了这么多的问题,跟你一个单身狗有什么关系呢?
还有,跟你一个已婚狗又有什么关系呢?
赶紧提Bug,改Bug去吧~~~第一章第三节的内容就到此结束
下节预告：
【三个环境：开发、测试、和线上】，敬请期待
欢迎来交流群与大家一起学习讨论，在里面进行实时的沟通答疑
微信分享人：
暗灭，出身搜狐，葡萄藤创始人/CEO，10年敏捷开发最佳实践
驻场大神：
搜狐产品大神张春源：10年+产品开发经验，高屋建瓴
冰秀大神：出身搜狐，连续创业，创业者的产品即是公司：一家被收购，一家上市，匠心独运
想进群的请加大师姐微信邀请进群：
记得备注学产品哟