这是一个创建于 3493 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天跟测试弄的有点不愉快，想必大家多少可以了解一些，有时候沟通交流存在问题，当然我自己也有原因，我只是觉得测试有时候提的bug，除了确实存在的bug，好像是为了追求bug数量，或者自己对需求不理解，或者根本不能这样测，不知道大家有没有这样的体会。
虽然bug对我们开发人员没影响，也不扣工资，解决了就好，但是我想请教一下大家，如何跟测试人员打交道，面对说不清楚，或者沟通困难的情况，该如何处理？
第 1 条附言 · 2015-06-09 10:28:01 +08:00
我们公司bug和需求都是当bug提，有时测试喜欢很多“建议”，他认为需求要改一下，提个bug，“这里建议XXXX”，这是产品的事情吧。
还有一句话可以说完的东西，分几个bug提。
……
我们开发做的东西确实存在很多bug，这里主要是讨论一些沟通上的问题。现在的问题是，因为沟通上的问题，说话的态度、语气，搞的很不爽。
还有一句话可以说完的东西，分几个bug提。
……
我们开发做的东西确实存在很多bug，这里主要是讨论一些沟通上的问题。现在的问题是，因为沟通上的问题，说话的态度、语气，搞的很不爽。
 |
1
Septembers 2015-06-09 00:12:58 +08:00
|
 |
2
jokester 2015-06-09 00:20:49 +08:00
觉得重要的改掉
不重要的让测试去和老板商量优先级 |
 |
3
loveuqian 2015-06-09 01:04:02 +08:00 via iPhone
楼主是做后端的？
我做了2年测试感觉前端问题是后端的几倍啊 怎么会今天上来发牢骚 |
 |
4
kalintw 2015-06-09 02:01:51 +08:00  3
1. "好像是为了追求bug数量"，
看公司的制度了，有些sx公司对测试人员有bug数量激励，不过这种sx公司应该消亡了吧。如果还有，赶紧走； 2. “或者自己对需求不理解” * 看项目流程规范了。正规公司尤其外企，Tester都是从Requirement/Specification阶段开始一起工作的，包括参与各种会议。有些外企，反而是BA和Tester最先接触项目需求或者客户，早于开发。 * 开发概要设计或者原型出来的时候，Tester那边的Plan/Risks/Test Points基本也都成骨架了。因此，如果出现Tester对需求不理解，说明流程有问题。 * 最不济，前还有个Test Plan & Test Cases Review吧， 开发也要参与的，至少听听/大体看看case介绍，目的就是找出遗漏、case设计不合理，甚至需求理解错误的地方； 3. “根本不能这样测” * 这个好说。因为如果是黑盒测试，或者end-2-end测试，测试人员考虑的角度就是用户角度，纯小白、纯透明角度。因为用户不会知道你咋实现的，不可能自觉的“我不能这样用”。 * 这点倒是开发和测试工作思考角度很迥然的一个地方，也最容易产生分歧的地方。 其实，本质都是为了和Requirement和Test Case对上号，“合格”出厂。 所以，沟通一下，有个track就OK，实在解决不了做不了主的就开会喽，不然头头是搞毛用的，就是拍板的。 另外，我朝对测试的不重视，流程的不规整，还有测试的薪水。。。整体上外企好一些，国内大厂好一些。 |
 |
5
timi 2015-06-09 08:38:41 +08:00
既然提出来了，说明客户有可能会按照这样操作 ，不妨参考一下
如果是可笑的bug，那就关掉或者不予解决。。。 |
 |
6
lifanxi 2015-06-09 08:58:04 +08:00
不应该有“根本不能这样测”想法，测试的基本价值在于发现问题，并不能去局限发现问题的方法和手段。
对于提交上来Bug，开发人员的第一反应应该是确定“这是不是一个问题”，而不是去想“这个问题重不重要”或者“这个问题要不要修”。如果不是问题就标为Not a defect，解释原因，与测试沟通，关掉。如果是问题，那就再去考虑它的优先级和处理方案。“Not a defect”、“Won't fix”或“Defer”对于开发来说都是不改代码，但是它们的含义和对后期的影响是不同的。 至于怎么跟测试沟通，测试也是人，人与人应该怎么沟通就怎么沟通。“说不清楚”、“沟通困难”并不一定是对方的问题。 |
 |
7
egen 2015-06-09 09:50:08 +08:00
有发现过“自己对需求不理解，或者根本不能这样测”的这种情况，特别是对一小部分不上心的测试人员
我们的解决办法是对该类 bug 标记 invalid，invalid 一般来说是测试人员对需求理解错误或根本就没看需求。 Bug 数量的奖励 和 invalid 是相互相成的，一个奖，一个惩。就我们运行的情况看效果还不错，基本上经过一段时间后就不会出现这种问题。 |
 |
8
zhicheng 2015-06-09 09:53:11 +08:00 via Android
B厂？
正规项目对于严重线上事故，测试要承担非常大的责任。所以重要修改都需要测试同意才可以上线。 只是这对测试的要求非常高，甚至高过开发。但B厂那些小孩儿，呵呵呵。 |
 |
9
tanteng OP @lifanxi 比如改数据库数据测，根本不是这样改。有的测试人员对技术基本不了解，你跟他讲为什么或者什么原因导致的很费力。
|
 |
10
geeti 2015-06-09 10:37:56 +08:00
测试水平这么差？
我们测试完全主导产品release进度，有的还负责code review.开发的人有的知识不知道了就找测试的问 |
 |
11
repus911 2015-06-09 10:44:27 +08:00
测试都是大爷！
好吧 玩笑 我们测试都是认真负责的妹子 我们测试跟开发都是在一个组里 有问题直接心平气和的说清楚就好了 前面有人说由于对技术不了解 解释很费力 这也有沟通上面的问题 不要把责任都推到测试身上 我们一般填好issue/ticket单子 包括需求文档的链接/邮件/直接内容、写好代码库/分支、环境准备命令、涉及到的功能 测试步骤 而且有时候 你在开发的时候就需要想到测试怎么测试 怎么跟测试解释你的思路想法 这也算是对自己逻辑的理论验证吧 可以加快测试速度减少返工次数~ |
 |
12
CinderellaCiCi 2015-06-09 11:02:14 +08:00
@Septembers 艾特我干嘛~
|
 |
13
ipconfiger 2015-06-09 11:10:03 +08:00 1
我一般采用爱抚的方式......
|
|
14
CinderellaCiCi 2015-06-09 11:13:01 +08:00
没什么好不愉快的。他追求bug数量，只能说明他们的考核机制制订的有问题。
找你们主管沟通下你遇到的问题，为何你觉得对方是在无理取闹，由你们主管去解决这个问题。（不然当这个主管干嘛，至于怎么解决是他的事） 我只能说，职场上，什么人都有。技术水平、处理问题的习惯、沟通技巧，你不能要求别人都与你在同一个平面和层次，要不怎么会有一些公司用各种方式评定和细化职位类别、能力层级、职级之类的？ |
|
15
lifanxi 2015-06-09 11:17:59 +08:00
@tanteng
测试有很多种，比如：功能测试、系统测试、压力测试、性能测试、探索性测试。 直接改数据库，把数据完全改成不可用（正常流程甚至出错流程中都不可能出现的情况）或者甚至把表都Drop掉可以看成是探索性测试的一部分。 各类测试要不要做，测试的期望结果是什么，都是可以在做测试计划时由项目经理、开发、测试一起来确定的。 当然，现实中肯定会遇到不靠谱的人，包括不靠谱的测试，也包括不靠谱的团队、不靠谱的领导。这时如何去沟通、如何去共同推进问题的解决，是一个更泛化的问题。但是有一个基本原则就是多想想“我能做什么去改变我不喜欢的现状”。 |
 |
16
yoa1q7y 2015-06-09 11:44:00 +08:00 1
我会根据QA的颜值去处理
|
 |
17
jasonding 2015-06-09 13:53:00 +08:00 1
哈哈，如果你碰到产品参与交付测试的时候给你提出N多奇奇怪怪的bug，你更要吐槽了。我之前的公司，产品参与测试后的结果就是:1、所有产品自己没想到的都认为是bug；2、所有产品在需求商定后的需求改动都认为是bug(哪怕是3分钟前他要求的改动)；3、(因为产品要求必须和原型一毛一样，像素级)觉得产品做出来不好看的，提开发的bug.......类似这种，楼主你觉得跟你们的测试比起来怎么样？
|
 |
18
iiilii 2015-06-09 14:02:26 +08:00
在我这无法复现
|
 |
19
ufo22940268 2015-06-09 14:30:51 +08:00
虽然bug对我们开发人员没影响，也不扣工资
lz这种逻辑感觉不是很好 |
 |
20
fxxkgw 2015-06-09 14:54:06 +08:00
我以前东家测试的都比较牛逼 无论是技术理论还是动手能力
当时两个资历差不多的 一个测试一个研发去面试鹅厂 前者轻松进去 后者技术面被卡住了。。 |
|
21
tanteng OP @ufo22940268 我不是说这样就无所谓了
|
 |
22
xubingok 2015-06-09 16:34:41 +08:00
简单来说:
如果是bug,改,别管他怎么操作出来的.能复现的必须改,不能复现的慢慢来. 如果是测试的"建议",或者他觉得应该修改产品需求.那就转给产品. |
 |
23
kyze8439690 2015-06-09 16:39:21 +08:00
珍惜测试人员，在一些小公司，没有测试人员，开发要自己做测试，那个才叫痛苦。
测试人员确保了质量，在上线前帮你测出了bug，帮你分担了责任。 |
|
24
kyze8439690 2015-06-09 16:40:50 +08:00
他认为需求要改一下，提个bug，“这里建议XXXX”，这是产品的事情吧。
实际上项目组所有人都有对产品提建议的权利和责任，应该多多提倡。 |
 |
25
tyriankid 2015-06-09 17:24:20 +08:00
”这里建议XXX“ 不完全是产品的事情。
是不是产品的事情取决于他提什么样的建议了。 若是真正意义上的“建议”，你可以认为他是在为产品操心，他只是想让产品做的更好，你鼓励与否，这个看你们。 但还有一种建议是“修改可能造成这个bug的原因”，难道你知道bug原因之后，以及某些地方可能会存在逻辑缺陷引发出更多的bug时，虽然这个bug还没发生，而你又没有权限去操作页面逻辑，那么你会不提建议吗？ 分几个bug提， 这个属于不好表达的一类bug吧。本着尽责的出发点，全部列出自然会让你们更容易判断。 毕竟两点一线，直捣黄龙。 |
 |
26
vietor 2015-06-09 17:29:44 +08:00
提bug之前先“嘴遁”确认一下，这样大家都感觉挺好的。
|
 |
27
jugelizi 2015-06-09 20:14:03 +08:00
遇到过死脑筋的 解释了原因后还认为是bug
|
 |
28
fate 2015-06-09 20:38:08 +08:00
我不会和测试一起打交道的,我只会和交道一起打测试.
|
 |
29
josephok 2015-06-09 23:18:03 +08:00 via iPhone
开发兼测试
|
 |
30
mcfog 2015-06-09 23:55:58 +08:00 via Android
测试和运维都是开发的重要(hao)搭(ji)档(you)，虽然前者一直在提bug，后者老不让你上生产，但最能帮开发分忧的也是他们，帮你减少线上bug少出生产事故的是他们，帮你提高系统鲁棒性稳定性，出事故时能有退路的也是他们，有这个心情和测试撕逼，不如约好一起去暴打产品狗（玩笑）
测试不了解需求，就推动他去了解需求。测试不了解系统，就介绍系统让他对总体结构有所认知。测试提建议型的ticket，就完善分级分类，优先级高的，blocking的解决，suggestion的improvement的可以即时做掉也可以延后。总之就是要协助测试让他能更顺畅地发挥他的作用，而不要“应付“他。 不如说无论是对测试还是运维还是产品还是设计，从协助对方的角度出发，一切好谈。毕竟团队里的每个成员的总体方向是一样的，你说呢？ |
 |
31
randyzhao 2015-06-10 01:08:22 +08:00
|
 |
32
frozen2013 2015-06-10 13:53:22 +08:00
个人感觉把提交bug的数量作为测试绩效考核的测试团队都是不懂开发和技术的。
例如鄙公司，测试都是手测，提的bug多，组长就认为工作好，还时不时自作主张提个改进需求，泥马客户都没提的东西。管项目也是搞笑，有时候用测试来催开发干活，督促进度。。。 所以如果是这种大环境上问题，改进个人方面的沟通也没多大用。 |
 |
33
zonghua 2015-06-10 14:06:07 +08:00 via iPhone
@lifanxi 中移动的iOS客户端，在点击获取验证码按钮后，按home键，再次进入，发现时间倒数是暂停的。这类问题属于什么？
|
 |
34
williamx 2015-06-10 19:46:56 +08:00
对你们的测试需要进行培训，告诉他什么是他的工作内容，需要他来管的，什么不是。
建议什么的，应该先指派给产品/策划，不应该提了个建议，但是指派到开发那边去。 说到底还是流程的问题（单大部分小公司根本不关心这个）。 |
 |
35
lalalanet 2015-06-10 22:54:52 +08:00
我一直认为QA工程师，先要是工程师，然后再会测试，写的代码比开发还好才配得上。
你们的测试人员太烂，辞掉重新招吧。你们公司要是不舍得招这样的人测试，你为难你现在的测试同事干啥。 |
Select Language