51Testing软件测试论坛

标题: 开发人员修改bug比较慢，测试人员可以做些什么工作来促进进度？ [打印本页]

作者: qd_pudding 时间: 2006-10-17 11:32
标题: 开发人员修改bug比较慢，测试人员可以做些什么工作来促进进度？
开发人员修改bug比较慢，测试人员可以做些什么工作来促进进度？
希望大家踊跃发言：）
sdlkfj3

作者: qd_pudding 时间: 2006-10-17 11:34
标题: 自己先顶
除了帮开发人员分析的每个bug的产生的可能原因? 我们还能做些什么呢

作者: xiaonan 时间: 2006-10-17 11:49
开发人员修改bug比较慢.找出慢的原因啊?可能还是你们公司的项目计划制定的不够完善.应该对开发修改bug有个规定要求.比如:测试人员每天下午3点提交BUG,并对BUG分好了级别.那么对于1,2级BUG开发人员必须当天修改.3,4级BUG必须第二天上午修改完毕.

作者: qd_pudding 时间: 2006-10-17 11:53
谢谢版主的回答
可是由于很多历史遗留问题：比如设计框架问题、异地开发问题、新员工不熟悉业务问题
这些都是修改慢的原因
在哪天改完也有做控制，但是在新版本中总会出现更多的新bugs
现在导致bug越来越多。。。
我们就只能等待开发人员不断地修改，我们不断的回归么

作者: luoyear 时间: 2006-10-17 22:15
对这些bug作一些分析
找出关键的问题关键的模块
必要时候对关键模块来一个大扫除

作者: archonwang 时间: 2006-10-18 12:09
修复延迟，需要首先分析导致慢速的原因，对症下葯。另一方面，需要通过行政、规范的手段控制修复成本。

作者: pang 时间: 2006-10-18 20:09
关键还是沟通吧，在我们这里，开发的都是领导，测试的就我一个小兵，bug提交了，人家都没空理我，只能是多和他们沟通，趁他们稍微空写的时候找准时机让他们修改……

作者: luoyear 时间: 2006-10-21 14:03
如果把bug解决的及时性作为绩效的一个环节会如何呢？
关键还是领导把不把它当作一个问题

作者: janezhang815 时间: 2006-10-25 14:03
标题: 向领导反映问题，由领导来推动
xiaonan 提的建议挺适用的

作者: qingzhou 时间: 2006-10-25 22:29
如果版本存在市场发布承诺还会这样吗?
应该不会吧,软件开发的流程没有做起来而已

作者: lee_huo 时间: 2006-10-27 16:20
bug修改的进度按原则不是测试人员督促的，这个活是项目经理的工作！

作者: yoyoa 时间: 2006-10-27 17:50
各施其职.测试人员只要把测试工作做好就非常好了,至于项目的跟踪,bug优先级别的修改,应该在其他人或部门来定义并完成.

作者: jiuyuetian 时间: 2006-10-28 13:14
需要测试人员对代码的要求比较高，找出BUG后注明是程序的哪部分代码的问题，这样开发人员修改的速度会快。

作者: 清水无香 时间: 2006-10-30 14:26
必要时发预警邮件给项目经理、项目负责人做，抄送给项目总监或更高一级负责人sdlkfj5

作者: hasis 时间: 2006-10-31 22:35

原帖由 luoyear 于 2006-10-17 22:15 发表
对这些bug作一些分析
找出关键的问题关键的模块
必要时候对关键模块来一个大扫除

严重同意,我们公司对于一些很不好解决的BUG均是通过开相关人员的会议,召集技术好的人员,共同讨论BUG出现的原因,讨论解决方案.以期最快解决.如果解决不了,freeze it.
但是,对于BUG的解决进度,最好还是由公司来下行政力量来加以管理,当然会根据BUG的级别,制定几点解决,但是有些人却是无视这些东西,那就只能通过领导压制来实现.项目永远是第一位的.sdlkfj8

作者: fxlizard 时间: 2006-11-9 19:39
首先我觉得,这个不是问题....

测试工程师是尽量多的发现Bug,Bug解决速度呵呵,我想不是工作重点.
当然,如果想改善一下协助关系...加快也是有办法的,就是提高BUG的质量,或者羞辱开发工程师! sdlkfj3

作者: cjycjy11 时间: 2006-11-13 11:04
甲：解决这个问题的涉及到很多，冠冕堂皇的说法是：制定并执行胡萝卜加大棒的绩效考核制度。
乙：。。。。废话！

作者: viviana_wdy 时间: 2006-12-9 15:13
标题: 测试人员的职责在于尽量找出问题在哪里
至于修改进度很慢一方面跟开发人员水平有关系，另外一方面代码设计没做好
但是催促开发人员改代码的事情的确不是测试人员份内事，你只需要每天告诉项目经理你的测试进度和有多少A,B,C,D,E级别的BUG，把你认为阻挡了测试进度的大问题概括的告诉经理，经理无论是叫开发人员谈话还是抽调人手或者叫他走流程，你都够不用关心，经理会比你更加关心项目的测试进度的

作者: 绿茶 时间: 2006-12-19 13:10
不做这种替别人着急的事情。谁最关心进度，就把这件影响进度的事情告诉谁。至于测试人员，只要做好自己的测试工作即可。

作者: wudamyw 时间: 2006-12-29 17:28
不用做什么，把你的报告发的客观，准确就行了，有人会督促这些事情。

作者: youzw 时间: 2007-1-3 21:40
测试人员的职责就是发现更多的bug。至于bug的解决，第一有缺陷处理实效来约束，第二有测试出口标准来保证。
版本经理和项目经理会关注缺陷处理情况的，否则一个版本达不到出口标准就可能下发不了了。

作者: dantianhua 时间: 2007-1-4 12:54
嘻嘻，你这个仅仅适用于白盒测试。
黑盒测试恐怕做不到这一点的。

原帖由 jiuyuetian 于 2006-10-28 13:14 发表
需要测试人员对代码的要求比较高，找出BUG后注明是程序的哪部分代码的问题，这样开发人员修改的速度会快。

作者: dantianhua 时间: 2007-1-4 12:56
嘻嘻，你这个仅仅适用于白盒测试。
黑盒测试恐怕做不到这一点的。

原帖由 jiuyuetian 于 2006-10-28 13:14 发表
需要测试人员对代码的要求比较高，找出BUG后注明是程序的哪部分代码的问题，这样开发人员修改的速度会快。

作者: Daniel_tan 时间: 2007-1-4 22:30

原帖由 pang 于 2006-10-18 20:09 发表
关键还是沟通吧，在我们这里，开发的都是领导，测试的就我一个小兵，bug提交了，人家都没空理我，只能是多和他们沟通，趁他们稍微空写的时候找准时机让他们修改……

sdlkfj9
有同感呀！！

作者: suncaijun 时间: 2007-1-8 09:30
我建议，提交的defact先提交给项目经理或者项目组长，他们来分析你报告的defact是否是正确的，正确的则分配给修复人并说明最后修复截止时间，或者延迟修复。有疑问的defact可以在跟提交人协商后，进行取消或者删除处理。

作者: wwwxzl 时间: 2007-1-8 14:50
根据情况而定,还是多沟通sdlkfj2

作者: skyqa 时间: 2007-1-17 12:43
我觉得需要规范公司的软件开发流程，比如缺陷管理流程：规定了缺陷的级别、严重程度，修改的时间等。单纯的测试人员来催促，是很难保证缺陷的修改和提高产品的质量的。

作者: angerswing 时间: 2007-1-17 13:09
无非是我们测试帮他们定位问题的所在，提出一些解决方案或替代方案给他们参考咯。哎，你要是只说出有BUG，人家也会看不起你啊，好像不编码就低一等啊。

作者: ccc11yyy 时间: 2007-1-17 17:46
我是自己写了一个邮件提醒的小程序，每天早上开发人员都会收到所有待修改的bug邮件，这也省去了测试去找开发的麻烦。

还可以把由于未及时解决的bug而引起的相关bug写到测试分析报告中，最好能结合bug修复成本，这样老大们会提高重视度。
至于追bug的修改效率，同意大家的观点，这不应该是测试做的事情。由关心进度的项目经理或其他高层来追，但是测试一定要把问题报出来让他们知道，这个是我们的责任。

作者: chengcai 时间: 2007-2-2 10:58
1、对测试出的BUG要进行定位，这样可以帮助开发人员进行快速的找到问题所在，也就可以提高修改BUG的速度。
2、对在内部测试的，规定好时间提交完BUG，规定好时间修改好BUG，这样硬性的时间点可以提高测试的效率和修改的效率
3、对不在本地的测试，有实施现场的，要灵活变动，对客户需要比较急的问题先修改，小的问题可以放到后面修改，另外对不能修改的问题要经过项目组讨论后进行是否保留还是删除或者是到下一版本实现。

作者: 杨小 时间: 2007-2-2 15:49
标题: 提交bug的一点心德
在项目计划时，计划出了测试时间，还应该给出开发工程师的修改时间，项目小时，bug 可以集中修改，没有必要发现一个，马上就需要更改另一方面，测试人员不要在下班之前把bug发给开发人员，让开发人员心里上由抵触心里，即使自己是在下班前完成测试，你的bug 也可以等到第二天在提交，很多开发人员讨厌在快下班的时候，有东西要更改

作者: purplelily 时间: 2007-2-8 16:32
标题: 个人见解
我们公司用URTracker来做一些工作流程的规范和控制。其中，软件缺陷管理是很重要的一环。每天，测试人员将bug提交到URTracker里；项目经理看到bug后，将bug分配给具体的开发人员去处理；开发人员修正bug后，交还给测试人员去确认。所有的步骤都有邮件提醒，URTracker里还有记录，根本不需要人去催。

进度上的事情不是测试人员份内去管的事情，所以lz不需要关心这个问题，只需要清楚的描述bug的症状，必要的时候复现给开发人员看，辅助他们定位到问题就可以了。sdlkfj2

作者: vigo 时间: 2007-2-9 18:06
考核缺陷的关闭率和关闭时间，我们就是这么搞的

作者: ccc11yyy 时间: 2007-2-13 09:42
缺陷在关闭前应该由测试人员进行回测，通过后再将其关闭的吧。考核缺陷的关闭率和关闭时间，是否是把测试和开发绑在一起考核吗？

楼上的，能详细的说一下你们的做法是如何促进开发人员修改bug的效率的吗？

作者: linyuanfu 时间: 2007-2-13 14:00
每个bug都有他的等级区别就如#3xiaonan所说的，如果流程规范的话，但是即使这样，这种情况也可能发生，因为累计下来，对开发人员来说每天都有很紧急或重要的事情要做，这个时候测试人员又认为bug一定要被fix，我想最快能解决问题的是要把这个问题提出并分析一下，然后让你的测试经理或项目经理来关注这个问题，最后的决定权是留给他们的．
直接去与开发人员讲这个bug需要修复不是一种很好的做法，他们也是有计划，这个不能不为他们考虑．sdlkfj3

作者: yxd2006 时间: 2007-3-3 09:44
3Q

作者: 鱼鳞 时间: 2007-3-7 08:52
如果他们修改慢是因为你的缺陷报告描述问题，那你就得加强自己的修炼，
如果仅仅因为他们的原因，那么做好份内事，其他的顺其自然，一次慢不会次次慢，因为肯定有一次他们会被K，即使你同时受责备，下次他们自然会抓好进度。

作者: 鱼鳞 时间: 2007-3-7 08:53
相信到现在楼主早已经处理好了吧?要把你的心得拿出来分享啊

作者: meiliqingdao 时间: 2007-3-22 18:24
还是公司管理比较混乱！如果测试人员提交缺陷报告单，交给测试经理，由测试经理做初步的审核。然后再提交给开发人员，做缺陷的定位。再提交给PM做评审。只有通过这样层层把关，才能保证，缺陷整个提交的过程不会脱节。

作者: 残月弯刀 时间: 2007-3-26 14:30
我觉得主要还是管理和沟通方面吧，开发人员应该每天有固定的时间来按级别修改bug，如果提交的bug级别比较高，而好几天又得不到修改，那应该是管理上的问题了，可能开发人员根本就没有看缺陷跟踪管理工具~~

作者: wujp_652 时间: 2007-4-11 19:03
提意见，提意见，过几天要推广，拿这个讲的～

作者: barcelona 时间: 2007-4-12 10:26
要是大公司有测试经理搞的小公司自己就多沟通下老

作者: barcelona 时间: 2007-4-12 10:29

原帖由 purplelily 于 2007-2-8 16:32 发表
我们公司用URTracker来做一些工作流程的规范和控制。其中，软件缺陷管理是很重要的一环。每天，测试人员将bug提交到URTracker里；项目经理看到bug后，将bug分配给具体的开发人员去处理；开发人员修正bug后，交 ...

我们也是但是我们用的工具不一样直接抱到clarif上交给开发他们，他们的leader 自动分配 fix 以后再给我们用邮件给我就是的恶嘿嘿貌似这个方法算是很好的了在clarify上还有一个discuss的地方

作者: huna0102 时间: 2007-7-6 17:35
公司管理问题，我也有同感。

作者: davids 时间: 2007-7-12 16:40
我觉得开发人员只要在下各版本提交测试前将上个版本的缺陷都修改就可以了，不一定非要规定缺陷的修改要及时。
重要的是我们在进行下个版本的测试有意义就行！

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