51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

测试开发精英班,通向高级软件测试工程师【周活动】 找茬--心里圈的故事 !【长期招募】博为峰网校招聘兼职讲师!横扫BAT,Python全栈测试开发技能大全
【106期】:如何树立正确使用Python做开发的习惯 【征稿】提交你的测试成绩单! 【专题】用尽一切办法只为让你学好用例 自学软件测试那点事
楼主: 默默巫

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

[复制链接]

该用户从未签到

发表于 2009-10-15 10:43:43 | 显示全部楼层
只有态度问题才需要惩罚。如果是能力问题,需要的是培训。
回复

使用道具 举报

该用户从未签到

发表于 2009-10-20 23:11:17 | 显示全部楼层
我们的最终目的不是追究责任
而是解决问题,让该现象不再发生或降低发生的概率
所以因该只是告诉整个团队“我们出现问题了,我们需要解决改问题”
回复

使用道具 举报

该用户从未签到

发表于 2009-10-28 15:30:12 | 显示全部楼层

需要

惩罚
回复

使用道具 举报

  • TA的每日心情
    开心
    2018-1-15 13:17
  • 签到天数: 486 天

    连续签到: 1 天

    [LV.9]测试副司令

    发表于 2009-11-2 11:24:05 | 显示全部楼层
    " 如果是很明显的bug,换其他任意一个人来都能发现,或者测试用例上已经明确有此检查点且测试人员给了通过的结论,那就真是这个测试人员的问题"

    有这种情况,功能1在上个版本测试时是正常没有问题的,但是在开发人员改了一些bug发布一个新版本后,那个原来测试过的功能1且出现了明显的bug。这也算测试人员漏测的问题吗,虽然每个版本都需要回归测试以保证原来没问题的功能仍然是好用的,但测试人员总不可能把所有功能都在每个版本都测试一遍吧,除非有很好的自动化测试脚本来保证,但现在自动化离我们似乎还比较远,即使自动化也不可能做到100%
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-11-3 11:33:36 | 显示全部楼层
    在目前国内测试还不规范的大环境下,我个人觉得漏测就惩罚是不妥的,毕竟"人无完人"啊.

    非常赞同61楼的观点!
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-11-4 11:10:24 | 显示全部楼层
    这个应该看情况的严重程度,当然不管是漏测还是bug修复的质量不好,这里都要注意一个问题,漏测的内容是什么,是测试用例的粒度不够还是文档描述的不够清晰还是其它什么原因,同样bug修复的质量不好是要看是bug描述不清楚还是开发人员自身的问题,另外惩罚只是一种手段,但不是并不是解决问题的方法。这需要大家的努力才能解决
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-11-5 16:05:32 | 显示全部楼层
    原帖由 lcldhlg 于 2009-9-20 15:25 发表
    我认为漏测并非所有责任都在于测试人员,因为引入这个BUG的不是测试人员而是在开发的时候产生了这个BUG,并且这个BUG可能很隐秘,测试的深度和广度并非无限的,有些BUG很难被发现。如果发现漏测的BUG,而这个责任相对 ...





    支持,支持,没测好要罚,测好了是本职工作,这是不对等的观念
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-11-5 19:08:57 | 显示全部楼层

    BUG是取之不尽,用之不完的。。。

    谁敢说一个回归开发一定能修复好
    谁敢说一个软件BUG一定全被发现
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-11-6 11:17:46 | 显示全部楼层
    * 视当前版本质量来看待,如果问题与新功能的比例在1:1的话,就处于可以接受的范围,就采取缓和一点的策略。如果
    严重超出范围,可以采取激烈一点的策略。
    h3. 缓和的处理方式
    * 出现问题必须要有相应的处理,但是处理的方式有多种
    ** 视问题类型和问题的严重程度,进行相应的处理(不建议针对某一次问题进行个例处罚。)
    *** 将此事件的过程记录下来,先找到出现问题的点在哪里:是流程环节出现问题、还是人员疏忽、还是隐藏问题?
    *** 单独与问题出现人员面谈,指出错误,听一听他的看法。
    *** 将问题作为关键事件记录下来,做为工作考核中的一个方面。
    h3. 激烈的处理方式
    * 将此事件的过程记录下来,先找到出现问题的点在哪里。
    * 对问题流程中的所有人进行处理,统一处罚。
    * 奖励团队中出错最少的人员(10%)

    想要提高软件质量,要靠开发人员。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-11-12 19:57:46 | 显示全部楼层
    漏测
    漏测并不是测试人员希望遇到的,只是在测试过程中没有发现bug的路径,在漏测出现以后测试人员更加注意这种环境下的测试,希望不要犯同样的错误。

    [ 本帖最后由 wang2171 于 2009-11-12 19:59 编辑 ]
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-11-13 23:09:06 | 显示全部楼层

    测试本身就是一项有风险的活动

    对一项有风险的活动由测试人员来负责不好的后果,不合理。
    但是可以根据“漏测”问题进行测试人员自身或者组织级的改进。因为也有可能是设计的用例不够完善,或者测试策略放弃了这部分的测试了...
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-11-15 14:49:20 | 显示全部楼层
    测试的目的是什么?终极目的应该是更好的测试者,而更好的软件只是这一过程的副产品。

    每一个漏测都是学习的机会。
    1. 为什么会漏测?
    2. 在软件的其他地方,还存在相似的问题么?
    3. 有没有办法增强测试用例,使得相关问题被及时地捕获?
    4. 测试团队从中可以学习到什么?增强的测试策略、改善的测试计划?
    5. 这个问题的根本什么?可以在开发阶段(甚至更早的阶段)就解决么?可以不通过测试就发现并解决么?
    6. 整个开发团队可以学到什么?

    要想更好地学习,就必须坦诚地承认错误,进行“无情”地分析。但是,“惩罚”会在客观上促使人人自保、文过饰非。推卸责任是很容易的,只要将所有问题推给他人就好了:项目的需求就搞错了;用户的环境与测试环境有区别(他的机器有4核CPU,我只有单核,这难道这是我一个搞测试的可以解决的?);我口头提醒过开发,但是他强调这是一个很酷的功能……

    “惩罚”的思路是“回避失败”,而不是“最求卓越”。卓越的文化不惩罚失败。但是培养卓越的文化非常困难,因此惩罚也是工具箱中的一员。应该先鼓励员工从错误中学校,然后组织团队有规划地学习,并尽可能地促进团队间的相互交流。惩罚只是最后的手段,是对无意学习者的提醒。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-11-19 14:46:48 | 显示全部楼层
    原帖由 velata 于 2009-8-4 23:49 发表
    惩罚的目的是什么?是为了那点微薄的RMB?还是为了提高项目质量?
    说说我们这边对两种情况的处理吧
    一、漏测
        我们漏测的概念是版本发布到客户那,由客户发现的bug。
        对于这类bug,先有开发分析这个bug的 ...


    说了一大堆,基本上都在点子上。罚款是可以的,但只是手段,提高质量,获得更好的客户满意度才是目的。何况,漏测这种事情,velata还漏了一种,就是项目计划阶段受到了过多的决策层压力,项目时间太短,无法完全执行的情况。那时候就只能听天由命。在这种情况下,测试也是有责任的,是能力不足,无法在预定时间内完成任务,但是并非一般能力问题,是特殊能力;开发也有责任,基本同测试。而板子也应该打到决策层身上,这帮人就不要推了,市场部仅仅给出了市场动向,给出了诱惑,而决策层决定吞下这枚果子,那么带进来的毒性也自然会扩散。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-11-19 14:51:54 | 显示全部楼层
    原帖由 jessies 于 2009-8-5 22:43 发表
    我对测试的看法就是,我同意允许发布的产品,如果发现问题,那么就是测试职责。
    如果一个测试拿“测试不能做到百分百发现bug”这个观点来作为漏测的理由,那么我只能说,测试人员的态度立场就是不太积极的。
    当然惩 ...


    罚款是一种手段,还需要对整个过程的反思:

    过程管理是否完善,是否有未经测试的版本发布?

    需求是否可操作,是否有测试人员的参与?

    需求是否稳定,是否频繁更改?

    需求是否明确,是否存在无法判断的标准?

    测试流程是否完善,是否每次都执行完所有用例?

    测试人员素质是否完善,是否能够完全理解需求?

    测试体制是否完善,是否有人监督测试员的用例执行情况,BUG汇报情况验收成果?

    开发与测试的沟通是否通畅?项目经理是否对开发偏袒导致BUG的强行关闭或挂起?双方经理是否达成过妥协,该协议是否文档化?

    许许多多的问题需要反思,这样看,罚款反而是很微不足道的事情了。
    回复

    使用道具 举报

    该用户从未签到

    发表于 2009-11-24 11:14:15 | 显示全部楼层
    测试是无穷尽的,不可能每种情况都被想到、被测试到。特别是刚接触公司产品的测试人员,随着对产品的了解越来越深,才会逐渐拥有良好的、开放的测试思维,测试的覆盖率才会越来越广。如果由于他的不了解就惩罚他,那么不但不会让他更加好的工作,反而会缩手缩脚起来。如果真的出现漏测情况时,我觉得不只是这个测试人员的过错,整个测试组的评审工作就是有疏漏的。测试组一定要将这个问题进行记录和总结,以备以后的项目提供借鉴。
    回复

    使用道具 举报

    该用户从未签到

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

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

    使用道具 举报

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

    连续签到: 1 天

    [LV.1]测试小兵

    发表于 2009-11-25 11:03:26 | 显示全部楼层

    支持一下。

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

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

    使用道具 举报

    该用户从未签到

    发表于 2009-11-25 14:52:59 | 显示全部楼层

    中立之个人浅见

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

    发表于 2009-12-1 16:32:54 | 显示全部楼层

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

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

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

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2019-9-17 06:40 , Processed in 0.070334 second(s), 24 queries .

    Powered by Discuz! X3.2

    © 2001-2019 Comsenz Inc.

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