无尽BUG的一生

发表于:2018-1-19 13:39

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:谭宇恒    来源:简书

  作为产品经理,每天都可以从各种渠道收集到各式各样的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已经在路上了,产品人,快去迎接他吧。

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号