无尽BUG的一生

作为产品经理,每天都可以从各种渠道收集到各式各样的BUG。因此,我们就成了名副其实的BUG接收器。既然成为了BUG接收器,那么BUG怎么接收,怎么处理,怎么验收就成了我们每天都要考虑的内容。下面我们就从BUG的接收、处理和验收,来讲述BUG的一生。

一、BUG的接收

首先,建立小组的BUGlist,用于提交收集到的BUG。在日常工作中我们发现BUG的渠道非常多,我们自己刷产品、测试人员测试、营销团队推广产品、用户反馈等。有的时候甚至是BOSS在和投资人讨论融资的时候,这个时候发现的BUG简直就是一颗炸弹,测试人员首当其冲。这些BUG都会统一提交到各个产品的手中,然后产品就会用自己的语言来描述BUG的情况和应该展示的情况,其中必要的截图和“应该是”等强调性词语的出现是很关键的。现在就可以提交这些内容到BUGlist,从提交的那一刻起,直到这个BUG彻底被消灭,期间所有的问题都将交由提交者来负责。

二、BUG的处理

BUG在处理过程中,要根据所开发产品的类型进行区分。主要分为WabApp和App。

WabApp

见于WabApp的灵活性,影响流程的BUG必须马上通知技术进行解决,如果不影响流程的类似于UI错误、文字错误、交互不佳等BUG我们可以等积累到一定数量后统一给技术进行交付。

App

对于App来说,有上线前的BUG和上线后的BUG的区别。上线前的版本,BUG主要出现在测试版的App上,因为可以随时修改的特征,我们可以像WapApp开发一样,及时处理严重的BUG,统一处理轻微BUG。对于上线后的BUG,在提交到BUGlist后,对测试版进行测试,如果测试版也出现了同样的问题,说明是测试人员检测上的疏忽,如果BUG没有严重到需要重新发版,那么就可以统一处理。如果BUG严重到需要重新发版,那么迅速交付开发并进行测试,修改后立即上传版本迭代。

三、BUG的验收

BUG的验收就是场景的复现,这个环节需要BUG的负责人亲自确认。在复现的过程中,可能要跑很多前置流程,可能要到后台进行调试,可能需要等待到特定时间、可能需要真实的支付、可能需要多次重复实验,不管验收过程有多么复杂,对于BUG的负责人来说,就必须亲自确认BUG已经修复,并且不再出现。这是一种工作态度,这也是责任心的表现。不能自欺欺人,用借口欺骗自己:“这个BUG应该已经好了。技术说BUG修复了就应该没问题了”。这样的疏忽,这样的借口都很有会给公司造成重大的隐患。是否为一个BUG的生老病死负责,也能判断一个产品人员是否有责任心。

BUG在完成以上三个环节以后,便结束了他的一生,但是这仅仅只是开始,快看下一个BUG已经在路上了,产品人,快去迎接他吧。

你可能感兴趣的:(无尽BUG的一生)