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

duzhy

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

愚人

为了共同的目标，前进……

Jon

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

freexml

考核应该只是起引导作用，最终在整个团队内形成一种适合公司文化的一致的质量观。

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

mengxb001

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

mengxb001

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

nanbowan

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

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

sherry.fen

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

liujun_newnew

鉴于此贴的探讨意义(可以大家提高软件开发质量和效率)建议版主将此贴置为精华贴。

liujun_newnew

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

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

lile

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

jotun

不同意这种做法，这样做是开发和测试的矛盾会越来越突出。

hxf

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

这只是个人的一点建议。

21muse

就遇到过一个。

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

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

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

九月属金

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

比较同意！

秋之水

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

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

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

jiangronghua

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

槛外人

不同意,那样的话,开发人员自己会花大量的时间自己测试,进度跟不上的,

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

m_2

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

goal0813

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