版本经理和项目经理会关注缺陷处理情况的，否则一个版本达不到出口标准就可能下发不了了。 嘻嘻，你这个仅仅适用于白盒测试。
黑盒测试恐怕做不到这一点的。
原帖由 jiuyuetian 于 2006-10-28 13:14 发表
需要测试人员对代码的要求比较高，找出BUG后注明是程序的哪部分代码的问题，这样开发人员修改的速度会快。 嘻嘻，你这个仅仅适用于白盒测试。
黑盒测试恐怕做不到这一点的。
原帖由 jiuyuetian 于 2006-10-28 13:14 发表
需要测试人员对代码的要求比较高，找出BUG后注明是程序的哪部分代码的问题，这样开发人员修改的速度会快。 原帖由 pang 于 2006-10-18 20:09 发表
关键还是沟通吧，在我们这里，开发的都是领导，测试的就我一个小兵，bug提交了，人家都没空理我，只能是多和他们沟通，趁他们稍微空写的时候找准时机让他们修改……
sdlkfj9
有同感呀！！ 我建议，提交的defact先提交给项目经理或者项目组长，他们来分析你报告的defact是否是正确的，正确的则分配给修复人并说明最后修复截止时间，或者延迟修复。有疑问的defact可以在跟提交人协商后，进行取消或者删除处理。 根据情况而定,还是多沟通sdlkfj2 我觉得需要规范公司的软件开发流程，比如缺陷管理流程：规定了缺陷的级别、严重程度，修改的时间等。单纯的测试人员来催促，是很难保证缺陷的修改和提高产品的质量的。 无非是我们测试帮他们定位问题的所在，提出一些解决方案或替代方案给他们参考咯。哎，你要是只说出有BUG，人家也会看不起你啊，好像不编码就低一等啊。 我是自己写了一个邮件提醒的小程序，每天早上开发人员都会收到所有待修改的bug邮件，这也省去了测试去找开发的麻烦。
还可以把由于未及时解决的bug而引起的相关bug写到测试分析报告中，最好能结合bug修复成本，这样老大们会提高重视度。
至于追bug的修改效率，同意大家的观点，这不应该是测试做的事情。由关心进度的项目经理或其他高层来追，但是测试一定要把问题报出来让他们知道，这个是我们的责任。 1、对测试出的BUG要进行定位，这样可以帮助开发人员进行快速的找到问题所在，也就可以提高修改BUG的速度。
2、对在内部测试的，规定好时间提交完BUG，规定好时间修改好BUG，这样硬性的时间点可以提高测试的效率和修改的效率
3、对不在本地的测试，有实施现场的，要灵活变动，对客户需要比较急的问题先修改，小的问题可以放到后面修改，另外对不能修改的问题要经过项目组讨论后进行是否保留还是删除或者是到下一版本实现。
提交bug的一点心德
在项目计划时，计划出了测试时间，还应该给出开发工程师的修改时间，项目小时，bug 可以集中修改，没有必要发现一个，马上就需要更改 另一方面，测试人员不要在下班之前把bug发给开发人员，让开发人员心里上由抵触心里，即使自己是在下班前完成测试，你的bug 也可以等到第二天在提交，很多开发人员讨厌在快下班的时候，有东西要更改个人见解
我们公司用URTracker来做一些工作流程的规范和控制。其中，软件缺陷管理是很重要的一环。每天，测试人员将bug提交到URTracker里；项目经理看到bug后，将bug分配给具体的开发人员去 处理；开发人员修正bug后，交还给测试人员去确认。所有的步骤都有邮件提醒，URTracker里还有记录，根本不需要人去催。进度上的事情不是测试人员份内去管的事情，所以lz不需要关心这个问题，只需要清楚的描述bug的症状，必要的时候复现给开发人员看，辅助他们定位到问题就可以了。sdlkfj2 考核缺陷的关闭率和关闭时间，我们就是这么搞的 缺陷在关闭前应该由测试人员进行回测，通过后再将其关闭的吧。考核缺陷的关闭率和关闭时间，是否是把测试和开发绑在一起考核吗？
楼上的，能详细的说一下你们的做法是如何促进开发人员修改bug的效率的吗？ 每个bug都有他的等级区别就如#3xiaonan所说的，如果流程规范的话，但是即使这样，这种情况也可能发生，因为累计下来，对开发人员来说每天都有很紧急或重要的事情要做，这个时候测试人员又认为bug一定要被fix，我想最快能解决问题的是要把这个问题提出并分析一下，然后让你的测试经理或项目经理来关注这个问题，最后的决定权是留给他们的．
直接去与开发人员讲这个bug需要修复不是一种很好的做法，他们也是有计划，这个不能不为他们考虑．sdlkfj3 3Q 如果他们修改慢是因为你的缺陷报告描述问题，那你就得加强自己的修炼，
如果仅仅因为他们的原因，那么做好份内事，其他的顺其自然，一次慢不会次次慢，因为肯定有一次他们会被K，即使你同时受责备，下次他们自然会抓好进度。 相信到现在楼主早已经处理好了吧?要把你的心得拿出来分享啊 还是公司管理比较混乱！如果测试人员提交缺陷报告单，交给测试经理，由测试经理做初步的审核。然后再提交给开发人员，做缺陷的定位。再提交给PM做评审。只有通过这样层层把关，才能保证，缺陷整个提交的过程不会脱节。 我觉得主要还是管理和沟通方面吧，开发人员应该每天有固定的时间来按级别修改bug，如果提交的bug级别比较高，而好几天又得不到修改，那应该是管理上的问题了，可能开发人员根本就没有看缺陷跟踪管理工具~~
