开发和QA的关系问题在软件圈内总是被津津乐道，这一周我们也凑个热闹，来聊一聊这两个群体的故事。

有一个典型的说法，开发和测试是作为对手存在的。考虑到测试工作的内容，主要围绕找BUG而展开，那么很容易被理解成挑开发的刺。于是，就会有一系列猫和老鼠的游戏;又或者测试人员“无中生有”地挑刺以及开发人员“强词夺理”般辩解。这样的故事和段子，可以说每天都在发生。

比如上周我们一个团队的开发和测试就为了BUG是否遗留缺陷的问题杠上了：

“小D，这个BUG麻烦你确认一下，是不是这次代码带动引入的?”

“小Q，我和你说，这个问题就是遗留缺陷，不是新BUG，我一眼就能看出来，这一轮不修。”

“能来点专业点的分析不? 这样子我很难向上交代啊。”

“你部个老版本测试一下，不就知道了。”

“不是来不及么，这个版本你们迟了两天才提交，我们都得加班才能赶上进度，哪有时间再部署一个版本啊。你们看一下代码不是很快的么?”

“说得轻巧，我也很忙的啊，手头的新功能今天还得提交，哪有闲功夫再看之前的代码啊。”

接下来整个对话开始争锋相对起来，围绕谁更繁忙以及对方是否在挑刺和逃避而进一步展开，颇有剑拔弩张之势，要不是项目经理及时介入，真的就不欢而散了。

那么，是否没有QA的世界，开发会过得滋润一些呢?

几年前，我们有个项目的开发和QA经常“吵架”。于是，有一次我们专门找了开发的组长探讨这个事情，大致意思：公司整体QA还挺缺的，是否可以把项目组的QA抽走，等过段时间再补其他的QA人员回来。结果，开发组长的反应让人大跌眼镜，他马上跳起来：这怎么行，没有QA我们怎么放心提交啊。吵架吵出的感情，绝对是真感情啊~~

一旦习惯了拥有QA的感觉后，没有QA配合的日子确实是挺难习惯的。这个大概是很多开发的心声了。

于是有了另外一类说法，有人称之为“暧昧”关系、甚至有人形容为“夫妻”般的关系。

我个人实际参与的项目以及身边接触到的场景，开发与QA还是非常和谐的;偶尔也会有矛盾，但是“对立”往往只是小插曲，而合作才是主旋律。因为不管是开发和还是QA，整个团队的核心目标是一致的：在一定时间范围内、高质量的提交;因此核心利益也是一致的。从这个点出发，没有必要“无中生有”、也没有必要“强词夺理”，因为这样小范围的“胜利”并不能给QA或者开发带来核心价值，反而会带来隐患。而双方可以更多思考如何通过两者的分工来保证或者提升项目的整体提交质量。

当然，核心利益的一致性只是提供了和谐关系的可能性基础，并不能保证一定会有融洽的氛围，在关系处理上会有很多微妙的成分，甚至还需要适当“吵架”调剂一下。作为QA，如何艺术性地处理与开发的沟通，绝对是一个让人深思的话题。

前两天在和一个客户交流软件项目的质量管理时，有人问起“当一个BUG在验证的时候，没通过怎么办，QA是否会要对开发有一些特别的要求和评价?”

我当时的回答：“我们的做法很直接，就是客观的Re-Open这个BUG，然后确认或者再分析这个BUG对于系统的严重程度;这个是QA的工作内容。但是QA不用评价开发、也不用有什么特别的要求，这个是他的主管该做的工作。”各司其职，切勿越界;这个也算是其中的一条相处之道了。

类似的，我也经常被问到这样的问题：“最后项目能否提交，QA是否有一票否决权?”坦白讲，这个问题并没有唯一的答案，不同的组织会有不同的决策政策。不过，仅从常规概念的各方职责而言，我的观点：QA根据自己和团队的工作给出质量的评价，以及从质量评价角度提供建议，并不承担是否提交的职责;“是否提交”最终还是项目经理的事。有了这个定位，很多时候就能摆正与开发、项目经理沟通的位置和态度，进而在职业的框架内处理一些潜在的“冲突点”。

而说起QA的“项目提交否决权”，又想起这两年在公司推进QA Sign-Off机制碰到的情况。所谓的Sign-Off机制，是需要开发线和QA线都签字确认，项目组方能按照正常手续提交。推行的时候，部分开发团队和项目经理有些不理解，觉得这个工作增加了提交的依赖，还降低效率，同时也没有实际增加软件本身的质量。事实上，做过管理的大都会有这样的体验，有签字和没有签字会是完全不同的感受，签字了代表着正式的承诺，进而会反馈到工作中。当然，在沟通的时候讲这样的大道理未必有效，于是我一般这么回答：“两者的区别在于：不做QA Sign-Off，提交出了问题，开发线和项目经理线承担主要责任;有了QA Sign-Off，出了问题，至少签了字的QA会承担同等的责任;相当于多了一个人一起来扛责任。”寻找利益共同点，应该是另外一个相处之道。

关于相爱相杀的“暧昧”关系这个提法，还有一个原因就是开发和QA的性别比例。这是一个非常有意思的话题，开发群体普遍男生多，而测试团队则女生比例很高。之前有不少时候，项目组的主管(甚至是开发的主管)跑过来和我要QA的时候，都会备注给一些女生，平衡一下团队的整体比例;而一些QA主管则会重点强调，来点男生，女生比例太高啦。同时考虑到IT男和IT女的社交圈，于是开发配QA的说法慢慢成为了经典。

我回顾了一下十年前我还直接带团队的时候，我们总计20个QA算上我也就5个男生;而对面30个左右的开发，常年女生人数小于5个，这还包括开发的女经理。最近我们聚会的时候，盘点了一下我们团队开发QA配的情况，不算跨团队的部分，仅仅是我们内部消化的，开发和QA结合的就有4对之多。这说明“夫妻”般的关系是非常有群众基础的，也为“男女搭配、干活不累”提供了事实依据。

文章的最后，分享一个十几年前我们团队的小故事。

在一次项目例会上，开发经理提出要和我对赌，对赌的内容：如果开发提交的下一个正式版本，QA发现不了BUG，那么我请整个团队吃饭;而如果QA发现了BUG，则由她请团队吃饭。面对送上门来的一顿饭，我当然是想都没想就答应了。当然，最开心的莫过于底下坐着的开发和QA们了，无论如何都有人请客啊。

但是故事远不止这么简单，会议后所有的开发们都像上了发条一样，想各种招预先做各类测试，单元的、集成的、功能的都使上。毕竟要是让自己老板掏了腰包，以后的日子肯定不好过啊。然后，没几天就有QA很为难地找到我：开发找我借测试用例，想拿去先自己测一遍;我们要不要给，会不会输掉啊。好吧，果然是什么招都用啊。当然，我还是面不改色、装得恰似内心毫无波澜地指示：要大度，能给的都给，开发能帮我们做测试是好事啊。

故事的结局，不出意料地，还是我们的开发经理请了客。“零缺陷提交”实在是有难度啊;但是，整个版本提交的质量无疑显著提高了。我相信我们的开发经理从最一开始就做好了请客的准备，但是用这样的方式做了一次提升质量的运动，营造了合力关注质量的氛围，所以本质上她还是赢了。

写到这里，自然开始有些怀念了，怀念那似乎从没有离开的团队，怀念开发和测试兄弟姐妹般的情谊。

以上内容来自达内软件测试培训老师们整理，更多测试小趣味欢迎点击官网了解哦!