google搜索 站内搜索                 软件测试门户 | 软件测试培训 | 文章资料精选 | 软件测试论坛 | 测试解决方案 | 软件测试博客 | 测试招聘求职 
打印

关于测试人员与开发人员的关系,请大家谈谈自己公司的情况

如果纯粹的用BUG的数量来考核开发人员是行不通的,很简单,现实工作中,工作量越多,产生的错误的几率越多。
   但如果不进行开发人员方面的考核的话,大部分开发人员是有惰性的,他们对自己编写的代码不负责任,不经过单元测试就直接丢给测试人员,造成测试工作的加重,最主要是来回修改错误造成项目的延迟
    解决这一矛盾,最主要是公司要建立一合理的考核机制,BUG 只是其中的一项而已,要跟工作量,工作难度,工作态度联系起来,但又不能忽视他们产出的代码的质量

   其实这是公司过程改进小组工作的内容

[ Last edited by 秋之水 on 2005-9-12 at 17:13 ]

TOP

引用:
Originally posted by 秋之水 at 2005-9-12 05:11 PM:
如果纯粹的用BUG的数量来考核开发人员是行不通的,很简单,现实工作中,工作量越多,产生的错误的几率越多。
   但如果不进行开发人员方面的考核的话,大部分开发人员是有惰性的,他们对自己编写的代码不负责任 ...
比较同意!
心烦意乱、夜不能寐!

TOP

我遇到过几乎零bug的开发人员


就遇到过一个。

还遇到过修改bug后返工率为零的一个开发人员。

这说明什么?说明开发人员可以做到“零”bug,前者是因为自己以前在一家大公司做过专职测试工作,后者则就是本人比较认真负责。

建议解决开、测人员间矛盾可以让新进公司的员工先做至少一个月的正规测试。
错了?改嘛!

TOP

不同意这种做法,因为,这样,会使测试人员和开发人员之间产生对立的矛盾。
这样对软件质量只有弊,而没有利。
但是,也要对开发人员进行考核,因为,一些开发人员,按照设计将代码写完了,就将程序仍给测试人员去测吧!往往,他们不做单元测试,就直接让测试人员去测。等测试人员测试出问题后,再去改。这样,就加大了测试人员的工作量。并且,浪费了很多时间,因为,开发人员未做单元测试,可能有些功能,他就将代码写完了,功能实现没实现,他都不知道,如果,基本的功能没有实现,测试人员将bug提交给开发人员,开发人员进行修改,但是,在修改过程中,测试人员就只能等待,因为,系统都不能运行了,怎么测试呀!(最后,只能调试和测试一起执行),但是,测试的时间是有限的,可能最后因为以上原因,使测试人员对软件没有进行充分的测试,就将软件提交给客户了。这样的软件会是高质量的软件吗?

这只是个人的一点建议。

TOP

不同意这种做法,这样做是开发和测试的矛盾会越来越突出。
*************************
嗟呼!草木无情,有时飘零。人为动物,惟物之灵。
百忧感其心,万事劳其形。

TOP

以楼主公司目前的状况,此举会加剧开发和测试人员之间的矛盾,不利于测试工作的进一步开展,对于开发人员在开发质量上的督促作用并不会有多少。所以不赞同这种做法。用bug率稍合适一点,就是每千行代码产生的bug比率。因为bug数和工作的难度以及工作量都是有关的,这岂不成了做得越多,错得越多。开发人员一定会有怨言。

TOP

总结一下:


1、提高软件质量不只是测试人员的事,开发人员也许更重要,尤其是其对自己代码的责任感、对测试的态度等;
2、评估开发人员和测试人员不能仅评Bug数作唯一依据,以下是一些参考:
      1)bug数量;
      2)工作量;
      3)工作效率;
      4)工作态度,尤其是勾通态度,包括积极、主动、热情、认真、温和、责任感等;
(附:3)和4)联合够成了开发人员与测试人员的配合度)
3、公司对开发和测试人员作恰当的评估有利于提高大家的积极性和热情,但是这个“恰当”很难把握,建议在不断尝试中不断调整和改进,让其更合理、更实际,最终达到更有效;
4、开发人员和测试人员的素质对公司采取的措施的有效性有很大关系:完全相同的策略,对于素质高的人来说,可能很成功,而对于某些人群来说,可能比不采取任何措施更加糟糕。所以制定策略时一定要考虑公司具体人员素质及特点。
5、开发人员和测试人员的工作是个联合体,根据公司的具体特殊情况有时会有特殊但合符实际的越位操作。比如我们公司在开发人员任务紧而测试人员较闲时,会要求测试人员帮助开发人员进行调试性质的单元“测试”,甚至单个功能的“测试”,还要用可能要花比开发人员自己定位问题多N倍的时间去用黑盒测试的办法定位白盒问题,但是从整体效率来看,这样是有利的。
……这是一个好贴sdlkfj2,很有探讨意义,大家继续……

[ 本帖最后由 liujun_newnew 于 2006-5-24 10:00 编辑 ]
Health is first;Time is second!
希望广交测试朋友和人生挚友……
QQ:253980289;MSN:lj253980289@hotmail.com

TOP

鉴于此贴的探讨意义(可以大家提高软件开发质量和效率)建议版主将此贴置为精华贴。
Health is first;Time is second!
希望广交测试朋友和人生挚友……
QQ:253980289;MSN:lj253980289@hotmail.com

TOP

其实我赞同考核,因为我们公司程序开发的产品是完全不测的,一开完了就丢给测试员。这样很费时间。如果早期能做白盒测试,也不至于开发人员总是要花好几个月来改BUG~~时间,人力,财力都是浪费

TOP

忠告


引用:
原帖由 duzhy 于 2004-10-28 20:10 发表
可能我叙述的不清楚,公司为了提高软件的质量,应该从源头抓起,做好写代码之前的分析设计工作和加强软件的单元测试。但是公司在没有加强这些工作的前提下,仅仅想通过测试发现的BUG数量来考核程序员,我认为这是 ...
如果能够说服公司上层,最好或者说“千万”别这样做。
前面已有网友分析过了,这样做弊多利少。而且影响很深远,如果将软件测试人员置于软件开发人员的对立面,可以预见,将来的软件测试工作将举步维艰,处处碰壁。
软件测试人员扮演的角色必须是软件开发人员的盟友,是帮助软件开发人员提高开发效率、提高软件质量的好帮手。千万不要误入歧途。否则,高层管理者将永远得不到软件质量得真实信息,而在一片扯皮中空耗精力。这也是很多成功软件企业在软件测试策略上得共识。

TOP

bug并不一定是由程序员产生的,程序一些缺陷本来就具有缺陷,在设计时候导致的缺陷在以后过程中很可能是无法修复的

TOP

在整个软件生命周期中软件开发只占有很少一部分时间,不要把责任都推卸给开发人员,但是产品出现了问题也不要把责任全部压倒测试人头上,这些是不合理的

TOP

 
当前时区 GMT+8, 现在时间是 2008-12-5 08:30Copyright(C)上海博为峰软件技术有限公司 2001-2007 电话:021-64471599-8017
当您在访问网站、论坛及博客过程中遇到问题时可发送email:webmaster@51testing.com或发送论坛短信至管理员风在吹