51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 10267|回复: 34
打印 上一主题 下一主题

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

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2004-10-27 21:32:38 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
有人说,开发人员和测试人员是矛盾的,这样才有利于软件质量的提高。我不这样认为。但是公司最近想通过测试部提交的BUG数量和级别来考核开发人员,我不太赞同这样作。
不知道各位所在的公司有没有这样做的,也请大家讨论一下开发与测试人员的关系问题。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏

该用户从未签到

2#
发表于 2004-10-28 09:09:07 | 只看该作者
公司这样做是正确的。
回复 支持 反对

使用道具 举报

该用户从未签到

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

使用道具 举报

该用户从未签到

4#
发表于 2004-11-2 10:24:36 | 只看该作者

比较同意公司的做法

回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2004-11-2 16:41:12 | 只看该作者

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

回复 支持 反对

使用道具 举报

该用户从未签到

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

使用道具 举报

该用户从未签到

7#
发表于 2004-11-11 16:23:00 | 只看该作者
单元测试是有必要的,但是通过测试人员发现的开发人员的bug数作为考核的话,会造成开发测试的矛盾
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2004-11-13 12:04:30 | 只看该作者

我觉得关键是公司要制定一套研发和测试的工作流程

回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2004-12-2 12:41:15 | 只看该作者
这样做显然是不妥当的,但是,如果有提交测试的功能根本没有办法使用的话,就得找研发的麻烦了,考核研发可以从这个角度去考虑!
回复 支持 反对

使用道具 举报

  • TA的每日心情
    郁闷
    2015-2-4 09:53
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    10#
    发表于 2004-12-15 15:39:07 | 只看该作者
    这只能是作为考核的一部分.我们公司就是这样处理的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2005-1-10 22:28:39 | 只看该作者
    我觉得只要时间允许,开发人员对代码进行一定程度的REVIEW,可以减少一部分的BUG,测试时会顺很多。减少一些中断系统的问题。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2005-1-12 21:44:34 | 只看该作者
    这样做是不切实际的,人为造成开发和测试的对立。软件质量的提高需要大家共同努力
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2005-1-13 07:33:40 | 只看该作者

    公司可以这么做,但不能简单去做

    每个程序员的模块不同,难易程度不同,不能一概而论。建议分析一下功能点(function point),如果一个模块有30个point,bug 有 2 个; 而另一个模块有10各point,bug有一个,那么哪个程序员的bug少呢? 还有,给function point 根据实现难度加上权重比例就更好了,只是工作量较大,不知道哪个公司愿意花这个精力。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2005-5-13 14:01:34 | 只看该作者

    不同意公司的做法

    如果公司想通过测试部提交的BUG数量和级别来考核开发人员的话,那不是很容易引起开发人员和测试人员之间的矛盾?我很不赞同这种做法,考核是有很多种途径和方法的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2005-6-29 16:56:31 | 只看该作者
    不同意公司的做法

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

    使用道具 举报

    该用户从未签到

    16#
    发表于 2005-7-4 09:39:41 | 只看该作者
    其实,这个做法我觉得也不一定正确,但一定情况下会有点道理.

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

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

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

    使用道具 举报

    该用户从未签到

    17#
    发表于 2005-8-27 15:57:11 | 只看该作者
    换个角度来看这个问题
    公司是怎么来评价一个测试人员的呢?
    单凭发现的bug数量?
    我想显然不是这样的。
    发现bug的能力只是其中一个评价点
    开发/测试人员的沟通能力,知识分享,对于工作的态度等等都应该作为评价的标准。
    真是所谓的综合素质~!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

    19#
    发表于 2005-9-1 14:11:47 | 只看该作者

    有关上面朋友说的这句话

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

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-5-21 17:36 , Processed in 0.080555 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表