你们是怎么跟测试打交道的？

[tanteng]

今天跟测试弄的有点不愉快，想必大家多少可以了解一些，有时候沟通交流存在问题，当然我自己也有原因，我只是觉得测试有时候提的bug，除了确实存在的bug，好像是为了追求bug数量，或者自己对需求不理解，或者根本不能这样测，不知道大家有没有这样的体会。

虽然bug对我们开发人员没影响，也不扣工资，解决了就好，但是我想请教一下大家，如何跟测试人员打交道，面对说不清楚，或者沟通困难的情况，该如何处理？

[Septembers]

@CinderellaCiCi

[jokester]

觉得重要的改掉
不重要的让测试去和老板商量优先级

[loveuqian]

楼主是做后端的？
我做了2年测试感觉前端问题是后端的几倍啊
怎么会今天上来发牢骚

[kalintw]

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，实在解决不了做不了主的就开会喽，不然头头是搞毛用的，就是拍板的。
另外，我朝对测试的不重视，流程的不规整，还有测试的薪水。。。整体上外企好一些，国内大厂好一些。

[timi]

既然提出来了，说明客户有可能会按照这样操作 ，不妨参考一下
如果是可笑的bug，那就关掉或者不予解决。。。

[lifanxi]

不应该有“根本不能这样测”想法，测试的基本价值在于发现问题，并不能去局限发现问题的方法和手段。

对于提交上来Bug，开发人员的第一反应应该是确定“这是不是一个问题”，而不是去想“这个问题重不重要”或者“这个问题要不要修”。如果不是问题就标为Not a defect，解释原因，与测试沟通，关掉。如果是问题，那就再去考虑它的优先级和处理方案。“Not a defect”、“Won't fix”或“Defer”对于开发来说都是不改代码，但是它们的含义和对后期的影响是不同的。

至于怎么跟测试沟通，测试也是人，人与人应该怎么沟通就怎么沟通。“说不清楚”、“沟通困难”并不一定是对方的问题。

[egen]

有发现过“自己对需求不理解，或者根本不能这样测”的这种情况，特别是对一小部分不上心的测试人员

我们的解决办法是对该类 bug 标记 invalid，invalid 一般来说是测试人员对需求理解错误或根本就没看需求。 Bug 数量的奖励 和 invalid 是相互相成的，一个奖，一个惩。就我们运行的情况看效果还不错，基本上经过一段时间后就不会出现这种问题。

[zhicheng]

B厂？
正规项目对于严重线上事故，测试要承担非常大的责任。所以重要修改都需要测试同意才可以上线。
只是这对测试的要求非常高，甚至高过开发。但B厂那些小孩儿，呵呵呵。

[tanteng]

@lifanxi 比如改数据库数据测，根本不是这样改。有的测试人员对技术基本不了解，你跟他讲为什么或者什么原因导致的很费力。

[geeti]

测试水平这么差？
我们测试完全主导产品release进度，有的还负责code review.开发的人有的知识不知道了就找测试的问

[repus911]

测试都是大爷！
好吧 玩笑 我们测试都是认真负责的妹子
我们测试跟开发都是在一个组里 有问题直接心平气和的说清楚就好了
前面有人说由于对技术不了解 解释很费力 这也有沟通上面的问题 不要把责任都推到测试身上
我们一般填好issue/ticket单子 包括需求文档的链接/邮件/直接内容、写好代码库/分支、环境准备命令、涉及到的功能 测试步骤
而且有时候 你在开发的时候就需要想到测试怎么测试 怎么跟测试解释你的思路想法 这也算是对自己逻辑的理论验证吧 可以加快测试速度减少返工次数~

[CinderellaCiCi]

@Septembers 艾特我干嘛~

[ipconfiger]

我一般采用爱抚的方式......

[CinderellaCiCi]

没什么好不愉快的。他追求bug数量，只能说明他们的考核机制制订的有问题。

找你们主管沟通下你遇到的问题，为何你觉得对方是在无理取闹，由你们主管去解决这个问题。（不然当这个主管干嘛，至于怎么解决是他的事）

我只能说，职场上，什么人都有。技术水平、处理问题的习惯、沟通技巧，你不能要求别人都与你在同一个平面和层次，要不怎么会有一些公司用各种方式评定和细化职位类别、能力层级、职级之类的？

[lifanxi]

@tanteng
测试有很多种，比如：功能测试、系统测试、压力测试、性能测试、探索性测试。

直接改数据库，把数据完全改成不可用（正常流程甚至出错流程中都不可能出现的情况）或者甚至把表都Drop掉可以看成是探索性测试的一部分。

各类测试要不要做，测试的期望结果是什么，都是可以在做测试计划时由项目经理、开发、测试一起来确定的。

当然，现实中肯定会遇到不靠谱的人，包括不靠谱的测试，也包括不靠谱的团队、不靠谱的领导。这时如何去沟通、如何去共同推进问题的解决，是一个更泛化的问题。但是有一个基本原则就是多想想“我能做什么去改变我不喜欢的现状”。

[yoa1q7y]

我会根据QA的颜值去处理

[jasonding]

哈哈，如果你碰到产品参与交付测试的时候给你提出N多奇奇怪怪的bug，你更要吐槽了。我之前的公司，产品参与测试后的结果就是:1、所有产品自己没想到的都认为是bug；2、所有产品在需求商定后的需求改动都认为是bug(哪怕是3分钟前他要求的改动)；3、(因为产品要求必须和原型一毛一样，像素级)觉得产品做出来不好看的，提开发的bug.......类似这种，楼主你觉得跟你们的测试比起来怎么样？

[iiilii]

在我这无法复现

[ufo22940268]

虽然bug对我们开发人员没影响，也不扣工资

lz这种逻辑感觉不是很好

[fxxkgw]

我以前东家测试的都比较牛逼 无论是技术理论还是动手能力
当时两个资历差不多的 一个测试一个研发去面试鹅厂 前者轻松进去 后者技术面被卡住了。。