1个版本,Bug 100+ ,爽 ?

2019-10-23 14:31:00
IDO老徐
原创
303


今天,本不打算写东西的 。看到测试群,很多Tester在抱怨,一个版本,测了100多个Bug 等 。

有必要聊几句 。


首先,

1个版本,100多个Bug,肯定是不正常的 。


还记得,那套理论么?Bug修复时间越晚,成本越高 。


如下,从搜索引擎随便搜了一张图(数据合理性暂且忽略,参考即可) 。

图略,见原文


1个版本,提测后,100多个Bug,什么概念 ?(见如上图的第三阶段 ,自行对比下) 。


那怎么避免此类问题 ?嗯,本文主要想写这点,怎么样让提测Bug少点 

(作者:老徐,http://isTester.com)

解决方案:

建立严格的准入标准 ,见之前文章:

准入标准、测试通过标准、上线标准


其实,文章里面写的挺详细的 ,包含 研发自测、冒烟测试、转测资料&说明&流程 等


上面文章有的,今天就不重复阐述了(大周末的,避免浪费阅读时间) 。


如果严格按这个逻辑执行,一个「两周一迭代的版本」,Bug控制在30内,是没问题的(具体还得看团队的磨合情况,及项目的类型、项目复杂度等) 。



接下来,说点异常情况 :


01


很多情况下,如上这套逻辑,是推行不下去的 。

理论很美好,现实很残酷(很多团队,那不是一般的乱;遇到问题,先不去想着解决本质问题,而是直接先来个996再说,如果还不能解决,997试试 …)。


如果实在无法推行研发自测、严格的准入标准 。

那么,IDO老徐 的建议是:

提Bug时,先提主要Bug即可,先修复一轮;

待提交新版本后,再提细节Bug 。提太多Bug,浪费提交录入的时间,开发查阅,也费时间 。



02

(作者:老徐,http://isTester.com)

来自某同学的提问:研发开发进度慢到吐,工期不能按时交工,测试该怎么做?我如果要催,该怎么催,关键人家也在工作,也没在闲着,就是忙,工作进度是他们自己定的,脑子疼。


如上,

很多时候,就是由于这种预估时间不准,最后上线时间定死,草草了事 。把未开发完成的半成品提交给测试,最后导致1个版本100+ Bug的情况 。


对于此种情况,普通测试能做啥 ?

“把现状,在项目群里,同步团队,说明没按时提测即可 。其他的,普通测试做不了 。



如果在普通测试的基础上,想往前推进一步呢 ?

(作者:老徐,http://isTester.com)

1. 这种属于任务拆分不合理(或者过于乐观,亦或技术障碍没提前预研),导致工时评估不准。

第一步,先去把任务拆分到1D颗粒度(需研发老大来推动这个事)


2. 每日站会进度同步,遇到的阻塞性障碍,及时解决;设置项目关键节点 ,有问题,及时抛风险 。

如上,先玩这两点,再观察一下 。


End 。


先聊这些,周末了,文章尽量短点 。

最后 ,

这几天,老徐花了十几个小时,把之前的测试资料,进行分类调整、文章调整、格式调整,进入V2.0时代,阅读体验更佳、资料质量更佳,公号「简尚」后台,回复“测试资料”阅读之 。


文 / IDO老徐

2019.10.18 深圳

本站申明

1. 本站点,所有文章,均为IDO老徐原创,拒绝转载 。博客地址 http://istester.com/

2. PC端,右上角,搜索框,输入关键词,可快速检索你感兴趣的所有文章 。

最新文章
公众号2



想了解更多 ?

欢迎关注老徐的公众号

Tester & 职场人 & 5W人都在关注

软件测试从业者综合能力提升&择业加薪 

第一时间,更新至此公众号

简尚公众号

长按二维码/微信扫码  关注老徐

老徐私人微信957863300

有问题,随时留言


软件测试QQ群


2000人高质量测试交流

软件测试QQ群

2000人软件测试QQ群


联系老徐
联系人: IDO老徐
Email: idolaoxu@gmail.com
QQ: 957863300
微信: 957863300
微博: isTester
网址: isTester.com
地址: 中国 . 广东 . 深圳