假如在版本发布前一天发现重要BUG应该怎么处理?
如题~ 当不知道。报告坏消息的人通常会被杀的,所以传令兵的死亡率一向很高。 告诉你的头,他说发布就发布! 作为测试人员
发现bug以后该怎么样还是怎么样
这个和版本是否发布没有关系
2#的如果面试的时候面试官问你这个问题
你会这么回答吗? 原帖由 puchonghui 于 2008-6-4 20:49 发表 http://bbs.51testing.com/images/common/back.gif
作为测试人员
发现bug以后该怎么样还是怎么样
这个和版本是否发布没有关系
2#的如果面试的时候面试官问你这个问题
你会这么回答吗?
现实情况是,在预定发布的状态下,没人想听到因为这样那样的原因前面的工作白费了。
如果测试报告了这个问题,导致了无法预期发布。最后追究责任,什么原因导致无法预期发布。这个时候,最大的可能性就是报告坏消息的人成为最好的替罪羊。
所以觉得,最好的方法还是当不知道。如果发布后出现问题,那么就和大家扯皮。
职场就是战场。 当然要赶紧告诉,不过注意语言的艺术,说话镇定点,语速稍慢,
不要让人觉得有因突发事件而引起的局部恐慌,
要让你的老板觉得你对此项目的高度认真负责的态度。
如果老板应压力过大,而急躁情绪,我看你和开发们就尽一切可能,不睡觉也要把bug除掉,做个尽全力的姿态也是必要的嘛!
宗旨:把损失降到最低,尽全力去处Bug。 论坛里有过类似的文章,自己搜索一下 我也觉得应该婉转的告诉项目经理或者老板,让他们应该知道,这应该是职业操守吧! 干嘛不能做到尽早发现BUG呢?
如果前期管理好,测试工作做的细致,就不会出现这样紧急情况。
如果面试的时候面试官问我这个问题,我就会告诉他,你们的测试管理有问题,赶快录用我,我帮你改善测试管理,包你软件发布顺顺当当!!! 强烈建议连夜赶写辞职报告。。。我是老大一定杀无赦!! 其实测试中这种问题还是不少发生的。隐瞒不报,你会死的更馋,因为测试是要有追溯性的,若你这个版本发现切是很严重的问题,那么上一个版本毕竟要对这个问题进行验证,因为这样开发才好排出是否是因为这次的改动而带来的bug,这样bug的root course寻找就排除了一个危险可能性。
所以对于测试人员来说对上版的验证是必要的,若这时你说你也发现了,那么我只能很遗憾的告诉你,不仅外边钉你 ,你老板也钉你。
但你若及时发现及时上报,至少这时你老板对外还能帮你抗。当然了,谁也不期望这种事情发生。可是谁也不能保证你的case能100%覆盖所有可能出现bug的路径。只能是从这一次的教训中吸取经验,来完善你的测试case。
当然,楼上有人已经说了你汇报bug的态度。这里就不重复,重要的一点,你要事先分析为什么你之前的测试没有发现这个bug,这个问题的发生机率有多大,是否是属于应该较容易发现的bug。其实分析这些也是给你自己开脱的机会,你要让老板知道这些分析,他才有话对外减轻责任。所以冷静的头脑是很重要的。 :( 我想这样在最后才发现的Bug,一是说明之前的测试做地不够全面,:victory: 二也有可能是,这个Bug不是那么容易能被发现,很可能是偶尔发生的缺陷,在特定的条件或环境下,才会触发;像这样的Bug要发现,已经是不容易,即使 找到后要确诊这是一个Bug,也需要一定时间,对于明天就要发布的软件,项目组要和时间竞赛,看看大家的身体素质如何?,不过昨天听了一段“山上有个坑”的故事,听完后觉得要是遇到这样的事情,还是要做个有心人,至少也要插个牌子什么的,以免死的人更多。
电脑这个东西,是让人类前进了一大步,但同时也可能给地球带来灭顶之灾,你想吧!要是一个军事软件发生了严重的bug,或是被骇客了,那些导弹、核弹乱飞...
我以前的老师这么说过, Why HCI?------->To save the planet.
改一改就是: Why testing? ------->To be safe.
好像有这么个电影是说这个的,哈哈,我能当导演了! 要看具体情况咯,在版本发布前一天发现BUG,我觉得应对BUG进行分析,看BUG出现在什么模块中,如果有必要就把存在BUG的的那个模块先关闭不发布或暂缓发布,待BUG修复后重新打开那个模块。 同意2楼的,职场这东西就是这样。:lol 原帖由 Giomy 于 2008-6-11 17:50 发表 http://bbs.51testing.com/images/common/back.gif
干嘛不能做到尽早发现BUG呢?
如果前期管理好,测试工作做的细致,就不会出现这样紧急情况。
如果面试的时候面试官问我这个问题,我就会告诉他,你们的测试管理有问题,赶快录用我,我帮你改善测试管理,包你软件发 ...
得了吧,人无完人,BUG永远是不可知的我们永远是被动的。 要知道改一个BUG意味着什么?意味着一个从未测试的新版本的诞生~!而明天就要发布。:victory:
再细化一点,如果这个BUG是个用户就能发现,那没办法,比如,启动软件就CRASH。那肯定是不行的。如果说同样是CRASH,但必须在用户操作了若干复杂步骤后或者说是一个概率性的CRASH,那在去冒着风险诞生一个新版本那无异于自杀。
比如这就有一个类似的BUG:http://bbs.51testing.com/thread-117301-1-1.html
[ 本帖最后由 baizhudan 于 2008-6-17 16:13 编辑 ]
回复 2# 的帖子
太过于简单,这样大家看不到具体的原因,还是需要看另外的帖子.浪费你自己的时间,也浪费我们的时间.回复 9# 的帖子
吹牛不上税吗? 报告上级上头说发布就发布,说不发布就不发布
1. 报告BUG是测试人员职责
2. 即使有严重BUG,也要让上级判断是否影响发布. 上级会根据利弊,选择适合的方案.
3. 即使提交BUG可以更早得修正.大家不要急,维护这个阶段又不是摆着看的.
4. 即使必须发布,也可以和用户先提出,让他们尽可能避免使用该功能,减少用户损失.
以上,请补充.:loveliness: 原帖由 Giomy 于 2008-6-11 17:50 发表 http://bbs.51testing.com/images/common/back.gif
干嘛不能做到尽早发现BUG呢?
如果前期管理好,测试工作做的细致,就不会出现这样紧急情况。
如果面试的时候面试官问我这个问题,我就会告诉他,你们的测试管理有问题,赶快录用我,我帮你改善测试管理,包你软件发 ...
到了实际工作的时候这位同学就明白理想和现实之间的差别了。
顺便问一句:
在培训的时候有没有学过: 就算前期的管理再好,测试工作做得再细致,这类紧急的情况也不是一定能够避免的。
[ 本帖最后由 逍遥剑客 于 2008-7-4 16:12 编辑 ]
页:
[1]
2