测试过程中是否应该按阶段有选择性的提交缺陷？

上一篇 / 下一篇  2014-10-29 09:50:43 / 个人分类：管理类

查看( 734 ) / 评论( 0 ) / 评分( 0 / 0 )
沟通管理是门艺术，沟通是否畅通，影响进度。

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

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

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

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

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

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

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

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

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

测试leader关于测试过程中发现的系统其他问题是否应该及时提交，与其他同事一起讨论。一部分人认为应该发现问题就提交，否则影响后期的测试工作量，测试leader方也有人一同认为应该有选择的提，提交的问题至于什么时候提，或者提交后是否及时要开发改，可以商量。目的是缓和目前这个不开心修改问题的状况。不知道大家在公司测试过程中是否也碰到过这种问题，你们又是怎么解决的？
-------------------------------------------------------------------------------------------------------------------------
产品测试过程中不论出现什么样的问题，肯定是都要提交的；但是对于不同的问题一定要有不同的处理方法；
开发人员认为不是此次提交测试范畴内的bug，可以先保留，在与产品的三方会议上进行讨论；要是范围内的就必须解决，没有商量的余地；

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

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

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

我们的考核都是按产品，测试和开发一起考核，产品不行（这个是最终专家组评审或审核），谁也得不了高绩效。
-----------------------------------------------------------------------------------------------------------------------------
为什么开发会和测试打交道？开发和测试交流只能是对问题本身的交流，比如测试人员有一个地方不清楚，可以去问开发人员，或者开发人员无法重新测试人员的缺陷，去询问测试人员。
对于一个缺陷，判断是否需要修改应该是项目经理的事情。什么时候修改，可以由项目组内部决定，这个根本和测试人员一点点的关系都没有吧。
测试人员只需要定期的出报告，说明测试情况，哪些改哪些没有改，着急的应该是项目经理，而不应该是测试这边。
对于有争议的缺陷，测试leader和开发manager可以商议，实在争执不下，可以向上提交审核。
在一个公司内，这样跨部门或组的工作，一定是组织对组织，而不是个人对个人。保持自己的立场即可。
--------------------------------------------------------------------------------------------------------------------------------
还有关于缺陷。缺陷是有自己的属性的，这些属性并不是随便存在的。
比如严重性，应该是从测试的角度看这个问题的属性归类；优先级是从开发的角度判断修改的顺序。
测试是有自己的态度的，这个态度不是对于开发组或者某一个人，而是对待一个程序的整体看法和判断。
从测试角度说，测试是一种对质量的度量，是对程序的一种基本审核，所以遇到问题，应该第一时间提交，不能按照开发的的角度去处理测试的问题。
写程序开发人员强，但是对于测试，应该还是专业测试人员的判断更准确。
测试人员要努力做到专业、职业，而这些最基本的就是要保证自己的话语权，不能随便被别人带走。
像我原先说过一句话：发现缺陷的时候，测试最大。
------------------------------------------------------------------------------------------------------------------------
测试是对产品阶段性质量的一中保证，测试过程中发现问题，是肯定要提交反馈的。个人认为任何一个项目，在阶段性计划未完成前，是不能轻易发布版本的，既然发布了版本，就以为的该阶段性工作已经开发完毕，那么提交阶段性测试后，测试人员发现的问题可定是属于该阶段性计划内的一些质量相关问题。

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

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

测试人员做好自己最本质的工作“发现问题，提交缺陷”，就是最好的工作方式。


收藏 举报

TAG:

 

评分：0

我来说两句

Open Toolbar