51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 78175|回复: 94
打印 上一主题 下一主题

“漏测”的测试人员需要惩罚?(2009-8-4)获奖名单已公布

[复制链接]

该用户从未签到

跳转到指定楼层
#
发表于 2009-8-4 10:03:57 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
背景描述:对于“漏测”的测试人员以及“回归测试不通过”的开发人员需要惩罚吗?


奖项获奖名单奖励答案连接
最佳话题PK手velata
价值50元的当当网礼品+最佳PK手勋章
3#


如果你也有矛盾的问题想提出来和大家一起讨论,请点击此处>>
说不定下期PK的话题就是由你提出的哦,请快快参与吧
正方观点 (218)

需要

反方观点 (500)

不需要

分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

94#
发表于 2014-7-8 23:37:44 | 只看该作者
就近两年的测试经验来说,不敢苟同国内大多的软件文档,很大实行敏捷开发的项目基本上就没有技术文档及用户手册,这就给测试人员很大的压力,测试依据在哪?只能通过口头上与开发人员或客户交流,这样就很难不出现漏测的问题。还是倡导规范软件开发过程吧。。。
回复

使用道具 举报

该用户从未签到

93#
发表于 2014-3-19 17:00:32 | 只看该作者
要惩罚!
回复

使用道具 举报

该用户从未签到

92#
发表于 2014-3-19 16:59:52 | 只看该作者
漏测,要分情况的,如果一个很容易就复现的问题,那是测试的责任,如果不在需求之列,那就不应该是测试的责任,惩罚应该是漏测与该测试人员工作绩效挂钩。
回复

使用道具 举报

  • TA的每日心情
    开心
    2020-3-30 15:30
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    91#
    发表于 2013-5-13 15:30:00 | 只看该作者
    需要惩罚的!!
    可以根据问题发现的难易程度来决定惩罚的力度。
    回复

    使用道具 举报

    该用户从未签到

    90#
    发表于 2012-4-17 16:33:31 | 只看该作者
    我惊呆了,好贴啊,很难得的好贴












    http://user.qzone.qq.com/695011108/infocenter
    回复

    使用道具 举报

    该用户从未签到

    89#
    发表于 2011-11-16 16:55:55 | 只看该作者
    山西气★枪,汽★狗专卖,QQ:859-365-828,柳州汽★枪,猎★枪专卖
    回复

    使用道具 举报

    该用户从未签到

    88#
    发表于 2011-7-20 13:59:51 | 只看该作者
    我以前所在公司就碰到过一次漏测事故。
    原因是没有对需求仔细分析,用例漏了。。。
    不能太怪测试人员,测试小组负责人管理组织不善,也是重大原因~
    回复

    使用道具 举报

    该用户从未签到

    87#
    发表于 2011-5-31 22:39:35 | 只看该作者
    缺陷是不可能完全被发现的,但是99.99%的严重缺陷是可以被完全发现的

    如果在计划内的测试活动都保质保量的完成了,遗漏一些小bug,应该达成谅解。
    但是如果出现严重的软件事故,测试leader有不可推卸的责任。
    回复

    使用道具 举报

    该用户从未签到

    86#
    发表于 2011-5-5 13:40:06 | 只看该作者
    回复

    使用道具 举报

    该用户从未签到

    85#
    发表于 2011-5-5 13:39:52 | 只看该作者
    回复

    使用道具 举报

    该用户从未签到

    84#
    发表于 2011-4-21 12:00:35 | 只看该作者
    这要依漏测bug情况而定
    回复

    使用道具 举报

    该用户从未签到

    83#
    发表于 2011-4-12 15:29:19 | 只看该作者
    回复 23# jiangmeiyu


        测试不可避免遗漏不是借口,是承认事实存在,就好像你承认自然界中有某些昆虫,你没法发现一样。
    回复

    使用道具 举报

    该用户从未签到

    82#
    发表于 2011-4-12 15:23:50 | 只看该作者
    既然提出漏测,那肯定是捅了窟窿了,要罚,连谁制造的,谁没测出来的,谁监督的,一并罚了,才算公平,才有效果,否则只能是苛责一直追求完美,却无法不犯错的替罪羊。
    回复

    使用道具 举报

    该用户从未签到

    81#
    发表于 2010-1-6 12:54:57 | 只看该作者

    1.怎么光说罚呢?
    2.如果测试的好,有奖励吗?
    3.现在的公司都很二,光说罚,不说奖。光想扣我们那点微薄的RMB
    回复

    使用道具 举报

    该用户从未签到

    80#
    发表于 2009-12-18 16:54:07 | 只看该作者
    大家在讨论这个的问题时,为什么没有将这个问题定义一下其概念呢?
    什么叫漏测,是版本发布后,客户或者其他公测人员发现的bug叫漏测呢,还是测试用例中存在的而没有发现的问题......
    同时什么叫回归未通过?是原来的问题根本没有改,还是改了又产生新的问题,或者说让其他功能或者模块产生问题.......
    定下标准后,我们再讨论是不是要惩罚,惩罚会带来什么影响,惩罚的利弊.......
    回复

    使用道具 举报

    该用户从未签到

    79#
    发表于 2009-12-1 16:32:54 | 只看该作者

    漏测不是测试人员一个人的责任

    作为一个测试人员和测试管理者,我个人觉得漏测不是测试人员一个人的责任,你们的管理流程上肯定也是有问题!首先如果你的测试用例是规范化管理的话,比如用TD或BUGZILLA管理的,漏测得情况几乎不可能发生;其次,一个系统在测试过程中,不要让同一个人始终负责同一个模块,要有轮换制,这样才能更多的发现问题。

    关于回归不通过的问题,我只能说有可能是开发人员的问题,也有可能是添加新功能对原有的功能有影响,这不能一概而论!
    回复

    使用道具 举报

    该用户从未签到

    78#
    发表于 2009-11-28 11:20:12 | 只看该作者
    这个要看公司的管理情况。
    在开发中和测试中,公司的制度就应该有所约束,而不是一味的事后罚款。
    当真正到事后,对于项目时间长,拖拖拉拉的项目,罚款也预示无补啊。
    对于测试人员的漏测和开发人员的回归测试不通过。最难办的地方。
    互相扯皮,互相推卸责任。最容易得罪人的地方。
    回复

    使用道具 举报

    该用户从未签到

    77#
    发表于 2009-11-25 14:52:59 | 只看该作者

    中立之个人浅见

    我本人也是测试人员,以下是我对议题的亲身感受!
    1、漏测:
            漏测的发生是无可避免的。我们公司是做石油行业的软件。我们很多时候根本没有办法在公司将所有的问题测试出来,第一:缺少需要用到的硬件设备。第二:很多时候,需要的资料都是不全,需求也比较模糊,客户那边也无法说清楚。第三:石油行业有一些只有他们业内人士才知道的规则,我们当然无从入手。相信其他业务领域也会有一些这样情况,那这时候说要惩罚测试人员明显是不合理的嘛。
            当然如果说漏测的原因是某测试人员没认真做好工作,那惩罚也是活该,可惜这种情况毕竟很少。
    2、回归不通过
           这个对我们测试人员来说是很痛恨的事情,尤其是大面积不通过,开发根本没做修改(本人遭遇过,同情一下)。这要狠狠的惩罚(咬牙切齿一下)。
            当然很多时候,开发也并不是有意的。我们公司常见的缺陷未能修复的原因:1)缺陷复杂度很高,难修改。2)开发对业务需求不明确。3)帮其他开发人员修改缺陷,对缺陷认识不够。
           话题中提到惩罚,我想说一句,很多时候开发人员也很无辜的。缺陷难修复,有可能是此开发人员本身就只是一个初级开发人员,根本不具备那么高的素养去修复框架类的问题等。业务需求不明确,还有也有一部分是项目经理的问题。帮他人修改缺陷未通过回归被惩罚何其无辜啊!
    回复

    使用道具 举报

  • TA的每日心情
    郁闷
    2019-8-22 13:17
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    76#
    发表于 2009-11-25 11:03:26 | 只看该作者

    支持一下。

    今年因为漏测被罚款上千元的人路过。
    人的问题吧。太菜了,么办法。

    这里有没有开发人员过来参加辩论呢。
    回复

    使用道具 举报

    该用户从未签到

    75#
    发表于 2009-11-24 18:07:53 | 只看该作者
    首先必须理清'漏测'及测试的概念. 测试是为了保证产品的质量,尽早尽可能的发现可能存在的错误(包括需求\设计\软件系统\环境等),而不是必须找出所有的问题,从这个意义上讲,遗漏是可能存在的., 当然,根据实际情况而言, 对漏测 公司可以建立一些规则,什么样的范围允许,什么样的范围不允许. 对于一个低级错误, 一般则不允许,而对于一个复杂的或业务需求不明晰或后期代码随意调整而产生的错误,则可以归为允许范围;
    对于'回归不通过'的问题,也该具体问题具体对待, 一个单一的问题则必须单次完成,若其他潜在类问题,测试人员并未及时发现而产生的,则应该规避开发人员的责任;  而若因某一BUG引发 其他 较严重问题(即回归时测试人员发现新BUG由上一版本的BUG调整而产生,则也应做以规范.

    另, 无论是漏测还是修改不通过, 都不能作为单一的评判标准, 而对于 漏测数较少 或 修改质量较高的,应加以表扬奖励, 这样才能调动 成员的积极性,  一个团队 应该是积极向上充满活力的,而不是 在恐惧中生存
    回复

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-22 03:13 , Processed in 0.088767 second(s), 30 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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