51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 4170|回复: 12
打印 上一主题 下一主题

[讨论] 测试过程中是否应该按阶段有选择性的提交缺陷?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2014-9-5 17:27:48 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
沟通管理是门艺术,沟通是否畅通,影响进度。

工作中时常碰到一些不善沟通的员工,由于沟通不畅影响工作进度。现对日常项目中碰到的问题进行描述,并总结缘由。

某开发人员负责一个项目,该人不善言辞,平时的沟通口头的让人觉得他对于做的东西没有概念,上面领导让做什么就做什么,没有主观能动性。文字沟通时,更是许久才回复,语言言简意赅。据与该开发人员合作过的测试人员,普遍认为反应不及时,影响工作进度。

作为测试leader面对这种情况很着急,只好出面主动沟通。经过一段时间的相处,测试leader发现这个开发人员的确不好沟通。每周的项目组例会上,测试leader主动汇报测试进度,但是依然觉得平时的工作开展完全靠测试人员的督促完成,整体觉得合作较累。比如需要通知开发有待修改的缺陷,通知开发提交程序,与之沟通有异议的问题,缺陷库中答复简短,但是没有理由。对于拒绝的问题回复,更是让测试人员觉得开发没有理由强制性的拒绝了。比如以下的问题。

“测试人员:消息系统群组内的一个成员发消息后,其他成员接收消息,双击闪动的即时聊天消息图标,打开的是与发消息的个人间的聊天窗口,内容为空。应该打开的是群的即时消息窗口。

开发人员:目前无法实现。”

“测试人员:消息系统群组中发附件的发送方,在文件传输中也显示需要接收自己发的附件。发送方接收的附件应该屏蔽掉自己发送的附件。

开发人员:目前的程序就是这样的。”

看到这样的问题被拒绝了,顿时测试人员火气很大,感觉辛辛苦苦测试的问题,开发人员没有理由就拒绝了。作为测试leader抑制住火气,耐心的把所有拒绝的问题,先是与这个开发人员尽量沟通,确认。经过一轮的沟通,测试leader又去找了这个开发人员的项目经理,对有异议的问题,再次沟通,确认。如果项目经理不能解决,测试leader又去找了负责这个产品的产品经理,第三次沟通,确认。经过三轮纵向级别的沟通,确认。问题全部解决,测试人员觉得工作算是处理好了。

这个项目存在的沟通问题,一方面与开发人员的不善言辞有关,另一方面主要是该开发人员的态度和做事风格,让合作的测试人员很烦。站在开发的角度,测试提交缺陷没有讲究方法,测试人员提交的缺陷没有按照阶段有选择性的提交问题,不仅把本次升级改动的功能测试了,而且把发现了的系统中的其他一些问题也一起提交了。开发人员反馈,不属于本次测试范围内的缺陷没有必要提交。但是测试人员坚持需要提交,利益冲突关系吧。开发有修改bug及时性的考核,测试有质量把关的考核。

测试leader关于测试过程中发现的系统其他问题是否应该及时提交,与其他同事一起讨论。一部分人认为应该发现问题就提交,否则影响后期的测试工作量,测试leader方也有人一同认为应该有选择的提,提交的问题至于什么时候提,或者提交后是否及时要开发改,可以商量。目的是缓和目前这个不开心修改问题的状况。不知道大家在公司测试过程中是否也碰到过这种问题,你们又是怎么解决的?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

  • TA的每日心情
    奋斗
    2018-1-23 08:52
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    2#
    发表于 2014-9-6 17:14:37 | 只看该作者
    产品测试过程中不论出现什么样的问题,肯定是都要提交的;但是对于不同的问题一定要有不同的处理方法;
    开发人员认为不是此次提交测试范畴内的bug,可以先保留,在与产品的三方会议上进行讨论;要是范围内的就必须解决,没有商量的余地;

    另外测试人员的测试范畴,这个应该在制定测试方案和计划的时候就要定下来的并且需要经过测试和开发的共同评审,不能由测试人员随便测试;如果乱测试的话也难免开发人员不开心,提了不少不是此次内容的问题。

    与开发人员的沟通,主要是有问题时提前沟通,不要直接提交,想想每天那么多不知所以然的bug(个人认为你们测试人员描述的bug水准有些差),难免生气;
    开发人员回复bug的内容一般都会有强制要求的:问题原因、处理方式以及解决的原理,最好都写上,这样对于测试人员还有以后的回归测试都有好处。

    还有对于测试和开发的考核,但看bug数的话有些绝对,不然为bug的事情打架就会很常见。

    我们的考核都是按产品,测试和开发一起考核,产品不行(这个是最终专家组评审或审核),谁也得不了高绩效。

    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    14 小时前
  • 签到天数: 3452 天

    连续签到: 62 天

    [LV.Master]测试大本营

    3#
    发表于 2014-9-6 22:45:32 | 只看该作者
    为什么开发会和测试打交道?开发和测试交流只能是对问题本身的交流,比如测试人员有一个地方不清楚,可以去问开发人员,或者开发人员无法重新测试人员的缺陷,去询问测试人员。
    对于一个缺陷,判断是否需要修改应该是项目经理的事情。什么时候修改,可以由项目组内部决定,这个根本和测试人员一点点的关系都没有吧。
    测试人员只需要定期的出报告,说明测试情况,哪些改哪些没有改,着急的应该是项目经理,而不应该是测试这边。
    对于有争议的缺陷,测试leader和开发manager可以商议,实在争执不下,可以向上提交审核。
    在一个公司内,这样跨部门或组的工作,一定是组织对组织,而不是个人对个人。保持自己的立场即可。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    14 小时前
  • 签到天数: 3452 天

    连续签到: 62 天

    [LV.Master]测试大本营

    4#
    发表于 2014-9-6 23:04:55 | 只看该作者
    还有关于缺陷。缺陷是有自己的属性的,这些属性并不是随便存在的。
    比如严重性,应该是从测试的角度看这个问题的属性归类;优先级是从开发的角度判断修改的顺序。
    测试是有自己的态度的,这个态度不是对于开发组或者某一个人,而是对待一个程序的整体看法和判断。
    从测试角度说,测试是一种对质量的度量,是对程序的一种基本审核,所以遇到问题,应该第一时间提交,不能按照开发的的角度去处理测试的问题。
    写程序开发人员强,但是对于测试,应该还是专业测试人员的判断更准确。
    测试人员要努力做到专业、职业,而这些最基本的就是要保证自己的话语权,不能随便被别人带走。
    像我原先说过一句话:发现缺陷的时候,测试最大。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
     楼主| 发表于 2014-9-9 14:19:24 | 只看该作者
    飞云天 发表于 2014-9-6 17:14
    产品测试过程中不论出现什么样的问题,肯定是都要提交的;但是对于不同的问题一定要有不同的处理方法;
    开 ...

    其实在以前的时候,我们也是按照产品来的,测试属于研发下的二级部门。最近几年由于公司组织结构的划分,测试和研发平起平坐,开发属于研发中心,测试属于质控中心,因为组织结构的转变和每个部门的目标不同,现在做测试属于组织与组织间的沟通,大家只顾个人的事情,其他的不会主动做。也可能因为公司设置质控中心要考核研发中心的项目进度,项目经理的绩效分数,项目分数等等吧,导致矛盾有点突出。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
     楼主| 发表于 2014-9-9 14:33:36 | 只看该作者
    luming 发表于 2014-9-6 22:45
    为什么开发会和测试打交道?开发和测试交流只能是对问题本身的交流,比如测试人员有一个地方不清楚,可以去 ...

    确切的说,目前研发那边存在职责不明情况,项目经理以下设置负责某项目的开发人员,而对这个开发人员可以定义为该项目的临时项目经理,所谓的临时项目经理没有什么权限,需要做什么,完成什么,进度,还是原来的项目经理考核,对于项目的发布,出现的问题,这个临时项目经理不负责也不反馈,只是自己决定是否修改,真正的项目经理只是每周例会时询问进度。实际碰到问题都是需要及时解决的,单凭在开例会时才汇报解决,影响项目进度。这种情况也让测试很被动,必须主动找真正的项目经理反馈,沟通,有时候跟他反馈,项目经理不明白情况,还需要找负责项目的这个临时项目经理具体咨询,搞的测试好像在找项目经理告状似的。感觉做事情时帽子扣的大一级了,但是干的活,怎么觉得还是原来的那套呢。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
     楼主| 发表于 2014-9-9 14:38:27 | 只看该作者
    自己顶下,欢迎大家一起参与话题讨论。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2014-9-11 15:26:58 | 只看该作者
    测试是对产品阶段性质量的一中保证,测试过程中发现问题,是肯定要提交反馈的。个人认为任何一个项目,在阶段性计划未完成前,是不能轻易发布版本的,既然发布了版本,就以为的该阶段性工作已经开发完毕,那么提交阶段性测试后,测试人员发现的问题可定是属于该阶段性计划内的一些质量相关问题。

    做测试的,肯定是有测试计划的,不可能拿来一个东西就像小毛驴拉车似地,头也不抬的测试下去,任何一个项目的测试人员也没有那闲功夫去测试那些没有开发的功能,因为这不在计划内。

    对于一个问题最终是否修改,最有决定权的因该是项目Leader,而不是开发人员,有争议的问题基本都是上报处理了,此时的交流就因该是部门组织间的交流而不是单纯的开发人员和测试人员间的交流。

    测试人员做好自己最本质的工作“发现问题,提交缺陷”,就是最好的工作方式。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
     楼主| 发表于 2014-9-17 17:22:12 | 只看该作者
    reven_baiyu 发表于 2014-9-11 15:26
    测试是对产品阶段性质量的一中保证,测试过程中发现问题,是肯定要提交反馈的。个人认为任何一个项目,在阶 ...

    是的,现在有问题就是找开发人员的项目经理沟通,跟开发人员有分歧的情况下,跟他们没有必要扯淡.
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2018-1-23 08:52
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    10#
    发表于 2014-9-21 20:52:46 | 只看该作者
    guofei318 发表于 2014-9-9 14:19
    其实在以前的时候,我们也是按照产品来的,测试属于研发下的二级部门。最近几年由于公司组织结构的划分, ...

    我们目前的也是两个部门,一个是开发,一个质量控制;但我们的一起考核跟部门的设置没有关系,两边还是各考各的,但是绑定的是项目和产品,项目和产品不好,两个部门的成绩都好不那去,年底绩效奖金啥的也都一样。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2014-10-7 08:37:00 来自手机 | 只看该作者
    感觉luming说的更合理。其实研发和测试本来都是为了产品的。总体考核可能更合适。但我不认同测试最大,永远都是产品和总体利息最大。如果一个缺陷推迟了整体的产品发布,而这又不是致命缺陷,肯定是不对的。用户和产品最大
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2014-11-5 17:10:43 | 只看该作者
    1、如果是项目组约定好的迭代交付测试,那就按约定好的计划交付范围提出问题,这需要测试人员自己要有判断能力,所发现的问题是否属于暂时未交付的范畴内。同时,测试人员提交缺陷一定要描述清楚,必要的时候可以统一测试人员提交缺陷的格式。从楼主所举的两个例子来看,如果是按此描述提交的缺陷,对于一些有个性的开发人员也许就会这样回复。
    2、测试人员在测试时要以用户的角度去考虑问题。
    3、对于沟通汇报方式,在测试启动时就要双方约定好,本帖中对于开发和测试的有争议的问题,可由测试leader不定期召开缺陷会议解决(周期可根据项目情况确定),会议其它参加人员:项目经理、产品经理,具体缺陷所涉及的开发,测试人员。时间不宜过长,每个缺陷3—5分钟必须下结论。
    4、也可在缺陷管理流程中增加一个拒绝(挂起)审核节点,具体由项目经理或产品经理负责。

    以上,如果还不能解决问题,暴力解决,谁不服气拉出去打一顿
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
     楼主| 发表于 2015-3-10 13:21:55 | 只看该作者
    目前,我们采用发现问题即提交,开发统一不改的,先与开发沟通,继续坚持不改的,与负责需求的人沟通,继续坚持不改的,测试可以保留,说明必须修改的理由,邮件通知项目组和自己的部门经理,不给于发布程序。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-5-3 14:52 , Processed in 0.078448 second(s), 22 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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