51Testing软件测试论坛

标题: bug出来后,程序员不肯改,那怎么办? [打印本页]

作者: merrymcj 时间: 2004-9-28 13:32
标题: bug出来后,程序员不肯改,那怎么办?
;)欢迎大家一起讨论,
bug tracking是我们测试人员比较头痛的事件之一

我们老大老开玩笑说:你们是女的,程序员是男的,要利用你们作为女性的优势拿出杀手锏......郁闷!

:s

作者: ghost 时间: 2004-9-28 13:42
标题: 对呀？咋办呢？
最怕是他认为不是BUG！

作者: merrymcj 时间: 2004-9-28 13:58
对,上面搂主说得很不错!
叫他们改更bug,他们最怕弄乱他们的宝贝代码.
楼上的,如果遇到这种问题,你们怎么处理?

作者: samlinzq 时间: 2004-9-29 15:18
公司本身应该有规定，对此类现像，开发人员无权决定不改，应由专门人员或小组讨论通过。

作者: 依伊卜舍 时间: 2004-9-30 10:07
楼上说得没错！

作者: hxf 时间: 2004-10-9 16:26
上报ccb，由组成员讨论，由他们决定这是否为bug,如果是，程序员他不改也不行呀！如果不是就直接关闭。

作者: bblily1015 时间: 2004-10-12 13:43
首先公司从开发制度上要有所保障；
程序员分析原因但无权决定改或不改，项目经理决定是不是Bug、或者确实是Bug但现阶段暂不改

作者: Lighthouse 时间: 2004-10-12 14:08
降工资。降奖金。看他改不改！

作者: archonwang 时间: 2004-10-12 18:06
测试人员也要自信起来，据理力争。

作者: ting_yt2 时间: 2004-10-13 16:32
可是很多时候和PM协调后 PM会说这是老问题了一直这样的这次不改或者说时间比较紧，下个版本再说吧亦或者说这个不影响的不用改了………………:s
我们小小的测试员怎么和PM争啊毕竟是他们说了算啊

作者: ting_yt2 时间: 2004-10-13 16:33
可是很多时候和PM协调后 PM会说这是老问题了一直这样的这次不改或者说时间比较紧，下个版本再说吧亦或者说这个不影响的不用改了………………:s
我们小小的测试员怎么和PM争啊毕竟是他们说了算啊

作者: vickywang 时间: 2004-10-13 17:30
我们公司发现错误后，首先提交给系统分析员，然后由系统分析员提交给项目经理。再由项目经理分配下去。
不过提交BUG时最重要的是要准确，不要误报，这样自已才有面子，哈哈。

作者: vickywang 时间: 2004-10-13 17:35
BUG改不改虽然说是由PM说了算，但是最终是用户说了算。要从用户的角度陈述问题的严重程度，才具有说服力。PM不会不注意用户的感受，软件只能我们自已拿来娱乐了。

作者: ting_yt2 时间: 2004-10-14 10:57

Originally posted by vickywang at 2004-10-13 17:35:
BUG改不改虽然说是由PM说了算，但是最终是用户说了算。要从用户的角度陈述问题的严重程度，才具有说服力。PM不会不注意用户的感受，软件只能我们自已拿来娱乐了。

所以关键还是在PM了毕竟PM还是要多方位考虑的比如时间比较紧，有些优先级不是很高的影响不是很大的bug就忽略了呀可是那确实是bug啊

奇怪，我前面那条回复怎么发了2条呢

作者: BigEyes 时间: 2004-10-18 14:06
测试人员工作重点是发现问题，报告问题。和程序员是否修改BUG没有必然的联系。如果测试人员注意总结，并拿出统计报告，积极和程序员沟通。这些问题就会迎刃而解的。

作者: QA_BAY 时间: 2004-10-19 11:54
对.,同意楼上的说法,程序员分析原因但无权决定改或不改，项目经理决定是不是Bug、或者确实是Bug但现阶段暂不改,在我们公司,当我们这些测试员没有把握时,我们就会请教经理,由经理去做,所以就不存在这样的问题,不过有时候,程序员根本不知道我们在说什么时,那时候才叫惨!

作者: luckhj 时间: 2004-10-22 08:52
"PM会说这是老问题了一直这样的这次不改或者说时间比较紧，下个版本再说吧亦或者说这个不影响的不用改了………………"
深有体会

作者: archonwang 时间: 2004-10-28 09:48
还是心态的问题。

作者: rosycloud 时间: 2004-11-1 16:57
这还在于公司是否有制度保证吧，如果公司把判断是否是BUG的权利交给了PM，测试人员可以提出自己认为的BUG，即使被PM否决了，但这个BUG可以作为记录保存下来，至少到用户认为也是BUG时，可以理直气壮地说明自己已经提出过这个问题了。

作者: plqueen 时间: 2004-11-30 09:01
同意樓主的看法

作者: 森林一木 时间: 2004-11-30 13:38
标题: 处理方式
我们公司的处理方式是:有测试组长进行过滤测试员提出的bug,测试组长将bug指派给PM,PM再进行过滤,最终指派给开发组长,进行bug的最终的处理,如果过程中,对于是否是个bug发生争执,必须有测试组长,开发组长,PM进行共同讨论,最终决定是否是bug,当然测试组长要有足够的理由说明那个问题是个bug,以及不修改带来的后果

作者: 西西 时间: 2004-11-30 13:59
首先，是bug提出的无误和简明
然后就是公司的缺陷管理流程的问题了
一个良好的工作流程，一般是不会出现这样的问题

作者: hqy0921 时间: 2004-12-10 14:59
如果bug本身不重要的话，并不是非要修改度达到100%，才能发布的，
这个不是测试员要求改程序员不肯改的问题，需要有个完善的测试制度，这个问题完全可以由“软件在什么阶段可以发布”对应规范来解决

作者: yliuji 时间: 2004-12-27 17:23
管理问题，不是技术问题。

作者: 依伊卜舍 时间: 2005-1-6 10:54
不是BUG应该要通过审核

作者: songfun 时间: 2005-1-6 18:13
我认为沟通的技巧很重要！真的！
这也是一种社会交际能力的体现，不要死板板的丢给程序员说：这个不行！你给我改！
会影响别人的情绪的话自然就矛盾了。

我觉得还是需要沟通，真的不一样！

作者: jackei 时间: 2005-1-6 22:06
敢不改！揍他们！！^_^

作者: cx0744 时间: 2005-2-10 11:07
不改可以，让他直接和项目经理说去，有项目经理决定改不改

作者: bill_hen 时间: 2005-2-11 02:56
改不改跟你测试人员有什么关系？为什么要头痛？
你只管submit 你认为的 bug，如果它被 fix 了，
你再检测，确认。
如果没有, 那就不是你的事情了，问都不用问。

作者: hxf 时间: 2005-2-16 15:51
这跟测试人员没关系，这应该是测试制度的问题，如果有一个明确的测试制度，就不会出现这种问题。

我们公司处理的方法如下：测试员先将缺陷提交给产品经理，产品经理看此缺陷是不是缺陷，如果是缺陷，它将此缺陷分配给相关的开发人员，如果认为不为错误，就和测试人员进行协调，将此缺陷管理；如果认为是缺陷，但是因为时间紧张或其他原因，将此缺陷推迟，将此缺陷状态置为respond状态。

作者: zamaz 时间: 2005-2-17 11:07
这要看开发组的项目经理怎样说了；他硬是不改那就把责任归他们罗，有什么好烦；我们只有把认为BUG或不合理的地方找出来提交了，责任已经到位；开发的不改也没办法。
当然这应该是少数者吧。而且公司也应该有制度来监督呀，如果还没有制度就建立，要保护自己的权益呀！

作者: joylq 时间: 2005-2-23 14:30
我也经常碰到这种问题，关键是测试人员能从用户的角度陈述问题的严重程度，如果还不改，我们会通知其直接上一级人员或者是PM来决定是否修改。

作者: j_dou 时间: 2005-3-3 13:42
楼上的说的很对，测试的确要从用户的角度去考虑，不仅仅要考虑到所有需求上的功能点、用户潜在的需求有没有都实现，业务流程有没有矛盾的地方，甚至连用户使用的方便与否，界面设计的合理不合理都是测试的范围。
关于提出的bug程序员不修改的情况，我觉得这个应该是测试工作流程方面的问题，需要测试部门的领导和开发人员的领导之间的沟通。有了明确的工作流程，这些问题就很好解决了。
还有一点比较重要，如果我们测试出有价值的bug，软件质量有了明显的提高，开发人员会很欢迎测试人员的。

作者: hxr2000 时间: 2005-3-6 15:14
标题: 当Bug处理有争议时，
应该进行Bug评审。不应该是谁说了算。

作者: qtest 时间: 2005-3-17 18:46
标题: 嫁给他！让他后悔一辈子！

作者: baitest 时间: 2005-3-17 20:56
楼上的，厉害！！

作者: 君羊 时间: 2005-4-4 16:46
我同意bill_hen
的观点

作者: baihong 时间: 2005-4-5 08:29
沟通虽然重要，但不应该作为唯一手段
不可能某测试人员和开发人员关系好，他提的bug就更能够得到解决，这样不是做公司，是在过家家。
应该由制度进行保证。
明确测试人员提出的bug由谁来决定是否更改（比如CCB或者开发经理），开发人员可以拒绝，但这个拒绝的过程应该在CCB和开发人员之间进行，如果CCB决定不进行修改，或者不在本版本中修改，那就放到下一版本去，测试人员需要做的，是保证提交的这个bug不丢失。
软件发布通常是由于时间到了，而不是bug都改完了。

作者: ybh2207 时间: 2005-5-27 00:37
记录下来交上去就可以了其他的交给公司制度去管理吧。

作者: zrg9399 时间: 2005-6-8 11:19
增加我们沟通能力，把问题讲清楚。开发人员会尊重你的测试结果的

作者: zrg9399 时间: 2005-6-8 11:20
增加我们沟通能力，把问题讲清楚。开发人员会尊重你的测试结果的

作者: goal0813 时间: 2005-6-16 11:14
1，公司内部应该建立起来应付这种问题的方法，比如开3方会议等，可以把这种 discuss的问题一并解决
2，测试人员职责是发现软件中存在的问题，将问题告知PM及项目组成员，由他们决定是否需要修改。（当然如果实在看不下去的话，应该据理力争）。

作者: goal0813 时间: 2005-6-16 11:14
to qtest:这招毒，毒，毒。。。

作者: 森林一木 时间: 2005-6-20 17:37
第一,公司制度完善;
第二,bug客观准确且严重级别定位恰当;
第三,沟通得当.
最后的结果:搞定BUG!!!

作者: texiang 时间: 2005-6-23 09:10
有的时候，企业内部的沟通要比对外还要难，这个时候，你要保证你提出的错误是存在的，然后才可以提交，通知程序员的方法，我不知道大家是怎么做的，但我认为没有必要直接去找程序员，大家在一个缺陷管理平台上，将错误反映上去后，然后通知程序员即可。
在项目进行中，要注意那些大的BUG，一定要使其处于关闭状态。如果在结束的时候还没有封闭，那么作为一个测试人员，有必要将此情况向上反映。对于小一些的BUG，如果在结束的时候还没有封闭，可以汇成一个清单，到时候如果出了什么问题，也有所依据。
不过有个问题也想和大家探讨一下，就是作为一个测试人员，从公司管理角度来讲，应该处于什么位置。各位在单位有没有一个专属的测试部门，部门的名称是什么

作者: Amsure 时间: 2005-6-23 20:13
bug的关闭与否应该有ccb讨论决定

作者: babel 时间: 2005-6-24 14:11
我们公司是由测试组定期进行绩效考核，在进行BUG票整理的时候，同时提交BUG修改率与BUG修改延迟时间度，
关乎他们的生存大计，看他们改不改！

作者: lonewolf 时间: 2005-7-1 10:22
不改就不改嘛，修改Bug要由项目负责人规定修改期限的，不是无限期的，而且还要高兴才改不高兴就不改，那样怎么能行！到时候会以这个因素去考核他的，他总是赖着不改，对他好像没什么好处，呵呵！

作者: 凡竹 时间: 2005-8-8 17:28
或许这些在他们眼里不是bug
只是一点小问题
无关痛痒，但是，我还是觉得软件还要完美点好~
所以，要让他们改~！

作者: gingko 时间: 2005-8-14 21:57
标题: Bug 到底改不改
在针对某一个问题是否Bug时，存在争议是正常的。因为有些Bug是显然的，比如实现和流程（标准）不符合，对于这些Bug因为有明显的依据，应该是无争议；对于另外一类bug，比如界面的风格，这些问题往往公婆各说，难以界定。出现扯皮是可以“接受”。
测试不仅仅是发现问题，测试要对一个版本负责，测试一个版本过后，应该知道这个版本是否可以发布，他的薄弱点在哪里，哪些需求没有实现。
从楼主述说来看，好像公司没有一套版本（需求）管理的流程，对于bug的界定没有一个开发和测试公认的标准。

作者: beck3000 时间: 2005-8-15 10:34
一般来说，对于一个项目中的bug，最后打开和关闭的权限还在项目内部处理，公司里即使成立了一个什么组织也没法决定这种具体的事务，关键还是沟通了。测试人员在处理上如果无法说服开发人员，最妥协的方式也应该是把这个缺陷推迟，而不是简单关闭，头痛之处其实在写测试报告时候，到底要不要反映这一问题，这个还要和项目经理沟通。
然后那位要嫁给程序员的MM，深以为此法不可行，一是如果多个程序员拒不改正，没法同时嫁给这么多人；二是连软件的bug都懒得改正的人，生活中的bug更不会改正了，后悔一辈子的怕是自己了。

作者: superhenry 时间: 2005-8-16 12:53
沟通，处事方式都有影响
有时你找的bug总是一个程序员的，而另外一个程序员的bug就很少
人家就对你不爽

作者: lyhcttyVoc 时间: 2005-8-19 10:08
如果提出的BUG与程序员有分歧，可以沟通了，再不行就把所有有问题的bug开会评估一下了

作者: dream_cui 时间: 2005-8-19 10:17
我提交BUG时候，分BUG和建议，开发人员认为不是BUG的，就给设计人说，如果设计人同意了，就让他更改设计，开发人员要按照设计更改程序的，他就不得不改了！

作者: hxf 时间: 2005-10-11 15:36
还是，公司有个正规的测试流程是主要的。是不是bug,将权利交给了谁的问题。

作者: johnjinwei 时间: 2005-10-11 20:15
这是一个测试流程的问题。当Release的时候是有一定标准的。（比如可以有多少级别的bug等），他们要违反流程的话，让PM去协调，把压力给那些PM。

作者: jeey 时间: 2005-10-13 09:57
我的想法是：测试人员是为了发现问题，提交BUG，跟踪BUG的修改，但不是去企求开发人员给我们修改，调试修改是开发人员的事情，但在这个过程中我们要运用技巧，沟通的技巧，软硬兼施，嘿嘿，要把问题和问题的严重性描述清楚，定期做个统计，提交给领导，由领导给他们压力比我们要有权威的多啊，而且也可以让领导看到我们的工作了，嘿嘿。

作者: allon 时间: 2005-10-21 10:40
拖出去打一顿！

作者: 落日 时间: 2006-2-15 15:20
如果公司有PM的话,就由PM决定了.
我认为测试人员不用想这些的,这是测试人员的职责之外了.
这是我做测试一段时间的深刻体会.

作者: Horus_Ra 时间: 2006-2-16 13:10
怎么办要具体看公司的流程怎么规定……
他实在不改就不改好了，你做你该做的，拿你该拿的就行了……

作者: tomzhang 时间: 2006-3-16 15:22
我觉得这是一个问题!首先要确定这真是一个Bug,然后提交,再由项目负责人分配,并修改;如果版本发布太紧急就放着,等到版本发布后在解决!但一定不要把它的状态改为"关闭"!然后就是制度的保证,版本发布一次后,要对bug更改的情况做个统计!

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)