51Testing软件测试论坛

标题: 关于测试人员与开发人员的关系，请大家谈谈自己公司的情况 [打印本页]

作者: duzhy 时间: 2004-10-27 21:32
标题: 关于测试人员与开发人员的关系，请大家谈谈自己公司的情况
有人说，开发人员和测试人员是矛盾的，这样才有利于软件质量的提高。我不这样认为。但是公司最近想通过测试部提交的BUG数量和级别来考核开发人员，我不太赞同这样作。
不知道各位所在的公司有没有这样做的，也请大家讨论一下开发与测试人员的关系问题。

作者: Lighthouse 时间: 2004-10-28 09:09
公司这样做是正确的。

作者: duzhy 时间: 2004-10-28 20:10
可能我叙述的不清楚，公司为了提高软件的质量，应该从源头抓起，做好写代码之前的分析设计工作和加强软件的单元测试。但是公司在没有加强这些工作的前提下，仅仅想通过测试发现的BUG数量来考核程序员，我认为这是本末倒置的。呵呵，说句实话，公司软件第一次测试我们可以发现非常多的BUG，往往要经过数次的修改测试才能过关。不知道大家的看法如何。

作者: sr 时间: 2004-11-2 10:24
标题: 比较同意公司的做法

作者: 杨菲儿 时间: 2004-11-2 16:41
标题: 不同意,那样的话,开发人员自己会花大量的时间自己测试,进度跟不上的,

作者: duzhy 时间: 2004-11-2 22:09
如果开发人员不作好单元测试，软件的质量得不到保障。光是修改测试发现的BUG就会浪费很多时间，会耽误更多的进度，而且需要用很大的精力来查找引起BUG的代码。
做好单元测试可以避免很多简单的错误，在系统测试时，测试和开发都会轻松的。

作者: Anitine 时间: 2004-11-11 16:23
单元测试是有必要的，但是通过测试人员发现的开发人员的bug数作为考核的话，会造成开发测试的矛盾

作者: pktest 时间: 2004-11-13 12:04
标题: 我觉得关键是公司要制定一套研发和测试的工作流程

作者: babybear315 时间: 2004-12-2 12:41
这样做显然是不妥当的，但是，如果有提交测试的功能根本没有办法使用的话，就得找研发的麻烦了，考核研发可以从这个角度去考虑！

作者: gu198031 时间: 2004-12-15 15:39
这只能是作为考核的一部分．我们公司就是这样处理的

作者: twinkestar 时间: 2005-1-10 22:28
我觉得只要时间允许，开发人员对代码进行一定程度的REVIEW，可以减少一部分的BUG，测试时会顺很多。减少一些中断系统的问题。

作者: dpgibson 时间: 2005-1-12 21:44
这样做是不切实际的，人为造成开发和测试的对立。软件质量的提高需要大家共同努力

作者: tangyi_toronto 时间: 2005-1-13 07:33
标题: 公司可以这么做，但不能简单去做
每个程序员的模块不同，难易程度不同，不能一概而论。建议分析一下功能点(function point)，如果一个模块有30个point，bug 有 2 个；而另一个模块有10各point，bug有一个，那么哪个程序员的bug少呢？还有，给function point 根据实现难度加上权重比例就更好了，只是工作量较大，不知道哪个公司愿意花这个精力。

作者: scenery 时间: 2005-5-13 14:01
标题: 不同意公司的做法
如果公司想通过测试部提交的BUG数量和级别来考核开发人员的话，那不是很容易引起开发人员和测试人员之间的矛盾？我很不赞同这种做法，考核是有很多种途径和方法的。

作者: jcstar 时间: 2005-6-29 16:56
不同意公司的做法

如果公司想通过测试部提交的BUG数量和级别来考核开发人员的话，那不是很容易引起开发人员和测试人员之间的矛盾?这样开发人员会花较多的时间在检查这个是否缺陷，导致缺陷的修复延迟，这就是目前我们公司的现象，这样做很不好，我很有切身体会

作者: madskill 时间: 2005-7-4 09:39
其实,这个做法我觉得也不一定正确,但一定情况下会有点道理.

首先,公司一定要从开发抓起,而并非测试抓起,测试不可能是开发的附属.而是开发的监督,不要认为开发结束了,就不用自己测试,单元测试和开发人员自测是十分重要的.这样可以避免很多很多的低级别BUG.这样会提高工作效率,测试人员也会发现更多更深的BUG,而不是一些低级别的BUG.(这个是从测试人员的心理总结的)

测试人员如果发现很多低级的BUG,那么一般就不会在十分注意更加深刻的问题缺陷了,同时开发人员也会觉得测试很烦,这些小问题都提出,开发会感觉没意义,从而矛盾就产生了.

所以,公司一定要从开发人员的编程素质和对工作的认真态度抓起,这个很重要,而不是让测试去替代开发.

作者: goal0813 时间: 2005-8-27 15:57
换个角度来看这个问题
公司是怎么来评价一个测试人员的呢？
单凭发现的bug数量？
我想显然不是这样的。
发现bug的能力只是其中一个评价点
开发/测试人员的沟通能力，知识分享，对于工作的态度等等都应该作为评价的标准。
真是所谓的综合素质～！

作者: m_2 时间: 2005-8-27 17:47
其实我觉得没有什么对与不对的！关键在于你怎么看待这个问题，公司这样做只是采取一种手段，来督促开发人员尽量提高开发的质量，对于测试人员来说，也是这样。公司这样做不是想搞得开发与测试相互竞争，他的目的只是为了让大家一起来重视软件开发的质量，而已！
这是小弟我个人的意见！！
哈哈

作者: 槛外人 时间: 2005-9-1 14:11
标题: 有关上面朋友说的这句话
不同意,那样的话,开发人员自己会花大量的时间自己测试,进度跟不上的,

晕，你还怕开发人员自己测试啊？这正是我们测试人员所希望的
开发完成后，必须对自己的代码进行充分的单元测试才可以提交过来的。如果说这样都耽误时间的话。那他不测试，就扔给你测，然后你发现问题，再反馈给他，这样就不花时间了吗？

作者: jiangronghua 时间: 2005-9-4 16:15
我来发表一些愚见：
考核开发人员的绩效，测试人员发现的BUG数量作为考核的一项指标的那是毋庸质疑的，这项指标是产品质量的一个关键因素。虽然目前我们公司还未实行，但我想很快就会。
上面很多朋友的说观点都很有道理，怎么来避免开发和测试的冲突？个人认为，只要开发和测试的目标一致，以项目最终完成所得到的奖金数目作为目标，我想就不会有任何问题了。

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

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

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

作者: 九月属金 时间: 2005-9-12 18:23

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

比较同意！

作者: 21muse 时间: 2005-10-11 13:40
标题: 我遇到过几乎零bug的开发人员
就遇到过一个。

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

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

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

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

这只是个人的一点建议。

作者: jotun 时间: 2006-5-17 17:35
不同意这种做法，这样做是开发和测试的矛盾会越来越突出。

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

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

[ 本帖最后由 liujun_newnew 于 2006-5-24 10:00 编辑 ]

作者: liujun_newnew 时间: 2006-5-24 10:02
鉴于此贴的探讨意义(可以大家提高软件开发质量和效率)建议版主将此贴置为精华贴。

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

作者: nanbowan 时间: 2006-6-5 10:59
标题: 忠告

原帖由 duzhy 于 2004-10-28 20:10 发表
可能我叙述的不清楚，公司为了提高软件的质量，应该从源头抓起，做好写代码之前的分析设计工作和加强软件的单元测试。但是公司在没有加强这些工作的前提下，仅仅想通过测试发现的BUG数量来考核程序员，我认为这是 ...

如果能够说服公司上层，最好或者说“千万”别这样做。
前面已有网友分析过了，这样做弊多利少。而且影响很深远，如果将软件测试人员置于软件开发人员的对立面，可以预见，将来的软件测试工作将举步维艰，处处碰壁。
软件测试人员扮演的角色必须是软件开发人员的盟友，是帮助软件开发人员提高开发效率、提高软件质量的好帮手。千万不要误入歧途。否则，高层管理者将永远得不到软件质量得真实信息，而在一片扯皮中空耗精力。这也是很多成功软件企业在软件测试策略上得共识。

作者: mengxb001 时间: 2006-6-20 15:46
bug并不一定是由程序员产生的,程序一些缺陷本来就具有缺陷,在设计时候导致的缺陷在以后过程中很可能是无法修复的

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

作者: freexml 时间: 2010-4-24 17:54
考核应该只是起引导作用，最终在整个团队内形成一种适合公司文化的一致的质量观。

如果管理层将该形式考核全量化，则会显得简单、粗暴，反而会导致测试开发之间的矛盾，
降低工作效率，最终得不尝失。

作者: Jon 时间: 2010-11-2 14:51
我只能说开发和测试的关系是协作的关系，只有把协作最大限度发挥出来，价值也就体现出来，那么最终我们的项目过程和结果就不然而语了

作者: 愚人 时间: 2010-11-2 21:17
为了共同的目标，前进……

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