51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: merrymcj
打印 上一主题 下一主题

[原创] bug出来后,程序员不肯改,那怎么办?

[复制链接]

该用户从未签到

41#
发表于 2005-6-8 11:20:09 | 只看该作者
增加我们沟通能力,把问题讲清楚。开发人员会尊重你的测试结果的
回复 支持 反对

使用道具 举报

该用户从未签到

42#
发表于 2005-6-16 11:14:05 | 只看该作者
1,公司内部应该建立起来应付这种问题的方法,比如开3方会议等,可以把这种   discuss的问题一并解决
2,测试人员职责是发现软件中存在的问题,将问题告知PM及项目组成员,由他们决定是否需要修改。(当然如果实在看不下去的话,应该据理力争)。
回复 支持 反对

使用道具 举报

该用户从未签到

43#
发表于 2005-6-16 11:14:52 | 只看该作者
to qtest:这招毒,毒,毒。。。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    郁闷
    2015-6-16 14:29
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    44#
    发表于 2005-6-20 17:37:08 | 只看该作者
    第一,公司制度完善;
    第二,bug客观准确且严重级别定位恰当;
    第三,沟通得当.
    最后的结果:搞定BUG!!!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    45#
    发表于 2005-6-23 09:10:47 | 只看该作者
    有的时候,企业内部的沟通要比对外还要难,这个时候,你要保证你提出的错误是存在的,然后才可以提交,通知程序员的方法,我不知道大家是怎么做的,但我认为没有必要直接去找程序员,大家在一个缺陷管理平台上,将错误反映上去后,然后通知程序员即可。
         在项目进行中,要注意那些大的BUG,一定要使其处于关闭状态。如果在结束的时候还没有封闭,那么作为一个测试人员,有必要将此情况向上反映。对于小一些的BUG,如果在结束的时候还没有封闭,可以汇成一个清单,到时候如果出了什么问题,也有所依据。
          不过有个问题也想和大家探讨一下,就是作为一个测试人员,从公司管理角度来讲,应该处于什么位置。各位在单位有没有一个专属的测试部门,部门的名称是什么
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    46#
    发表于 2005-6-23 20:13:35 | 只看该作者
    bug的关闭与否应该有ccb讨论决定
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    47#
    发表于 2005-6-24 14:11:18 | 只看该作者
    我们公司是由测试组定期进行绩效考核,在进行BUG票整理的时候,同时提交BUG修改率与BUG修改延迟时间度,
    关乎他们的生存大计,看他们改不改!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    48#
    发表于 2005-7-1 10:22:11 | 只看该作者
    不改就不改嘛,修改Bug要由项目负责人规定修改期限的,不是无限期的,而且还要高兴才改不高兴就不改,那样怎么能行!到时候会以这个因素去考核他的,他总是赖着不改,对他好像没什么好处,呵呵!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2020-7-9 15:04
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    49#
    发表于 2005-8-8 17:28:14 | 只看该作者
    或许这些在他们眼里不是bug
    只是一点小问题
    无关痛痒,但是,我还是觉得软件还要完美点好~
    所以,要让他们改~!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    50#
    发表于 2005-8-14 21:57:09 | 只看该作者

    Bug 到底改不改

    在针对某一个问题是否Bug时,存在争议是正常的。因为有些Bug是显然的,比如实现和流程(标准)不符合,对于这些Bug因为有明显的依据,应该是无争议;对于另外一类bug,比如界面的风格,这些问题往往公婆各说,难以界定。出现扯皮是可以“接受”。
        测试不仅仅是发现问题,测试要对一个版本负责,测试一个版本过后,应该知道这个版本是否可以发布,他的薄弱点在哪里,哪些需求没有实现。
       从楼主述说来看,好像公司没有一套版本(需求)管理的流程,对于bug的界定没有一个开发和测试公认的标准。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    51#
    发表于 2005-8-15 10:34:20 | 只看该作者
    一般来说,对于一个项目中的bug,最后打开和关闭的权限还在项目内部处理,公司里即使成立了一个什么组织也没法决定这种具体的事务,关键还是沟通了。测试人员在处理上如果无法说服开发人员,最妥协的方式也应该是把这个缺陷推迟,而不是简单关闭,头痛之处其实在写测试报告时候,到底要不要反映这一问题,这个还要和项目经理沟通。
    然后那位要嫁给程序员的MM,深以为此法不可行,一是如果多个程序员拒不改正,没法同时嫁给这么多人;二是连软件的bug都懒得改正的人,生活中的bug更不会改正了,后悔一辈子的怕是自己了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    52#
    发表于 2005-8-16 12:53:22 | 只看该作者
    沟通,处事方式都有影响
    有时你找的bug总是一个程序员的,而另外一个程序员的bug就很少
    人家就对你不爽
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    53#
    发表于 2005-8-19 10:08:27 | 只看该作者
    如果提出的BUG与程序员有分歧,可以沟通了,再不行就把所有有问题的bug开会评估一下了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    54#
    发表于 2005-8-19 10:17:25 | 只看该作者
    我提交BUG时候,分BUG和建议,开发人员认为不是BUG的,就给设计人说,如果设计人同意了,就让他更改设计,开发人员要按照设计更改程序的,他就不得不改了!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    55#
    发表于 2005-10-11 15:36:04 | 只看该作者
    还是,公司有个正规的测试流程是主要的。是不是bug,将权利交给了谁的问题。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    56#
    发表于 2005-10-11 20:15:33 | 只看该作者
    这是一个测试流程的问题。当Release的时候是有一定标准的。(比如可以有多少级别的bug等),他们要违反流程的话,让PM去协调,把压力给那些PM。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    57#
    发表于 2005-10-13 09:57:03 | 只看该作者
    我的想法是:测试人员是为了发现问题,提交BUG,跟踪BUG的修改,但不是去企求开发人员给我们修改,调试修改是开发人员的事情,但在这个过程中我们要运用技巧,沟通的技巧,软硬兼施,嘿嘿,要把问题和问题的严重性描述清楚,定期做个统计,提交给领导,由领导给他们压力比我们要有权威的多啊,而且也可以让领导看到我们的工作了,嘿嘿。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    58#
    发表于 2005-10-21 10:40:26 | 只看该作者
    拖出去打一顿!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    59#
    发表于 2006-2-15 15:20:49 | 只看该作者
    如果公司有PM的话,就由PM决定了.
    我认为测试人员不用想这些的,这是测试人员的职责之外了.
    这是我做测试一段时间的深刻体会.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    60#
    发表于 2006-2-16 13:10:13 | 只看该作者
    怎么办要具体看公司的流程怎么规定……
    他实在不改就不改好了,你做你该做的,拿你该拿的就行了……
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-15 15:48 , Processed in 0.078626 second(s), 21 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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