测试和开发可以说是前世的一对宿孽，今世的一对儿冤家。开发的工作就是按照 PM 的设计将产品最终造出来，而测试则是在开发已完成的工作里找错误，寻不是。显然，测试这样的工作会让开发很不爽，其实不但是开发，每个人都不喜欢自己的劳动成果别别人挑毛病。如果测试在工作中不讲究方式方法让已经比较紧张的测试开发关系雪上加霜。所以测试总是很容易就和开发们吵起来，吵得是鸡飞狗跳，就差上手了。这样的场景每天在不同的公司重复上演。

即使现在的测试大都是 90 后的小姑娘，肤白貌美，性格耿直，工作认真负责。 开发们也都是技术牛逼，性情良善的大小伙子。一旦偏偏工作起来双方闹得水火不容，最终需要 boss 的调停才能休战。

他们吵架的内容往往也是千篇一律：

测试：我提的 bug 为什么还没有修复？！
开发：哦，你什么时候提的 bug？提了哪些 bug？
测试：你没有看邮件？！
开发：哦，可是邮件那么多，我怎么看的过来。

测试：关于这个 bug 我都说了八百遍了，就算是猪也明白是怎么事了，你怎么就不明白呢？！
开发：哦，不懂，你再讲一遍。

测试：刚刚提的那个 bug 赶紧修复了！！！
开发：哦，可是你只给我几个名字，环境，步骤什么都没有我怎么重现，怎么修复？

测试：上次我给你说的那个 bug 都过了三天了为什么还没修复？！
开发：哦，可是你没说让谁去修。

总结下他们争吵的原因就这几个：要么是测试提的 bug 邮件开发没有看到，导致 bug 没有修复产生争执；要么是测试提的 bug 开发无法重现导致争执；要么就是双方关于 bug 的优先级意见不一致产生争执。

其实这些争吵完全是没有必要的，下面我结合自己的工作经历和大家聊聊如何做好测试工作并与开发和谐相处。

作为测试来讲，bug 管理是日常工作中非常重要的一项，这项工作的好坏直接决定了测试是否能和开发和谐融洽的相处。

以往的做法都是测试将新发现的 bug 一股脑儿的加到开发任务中，然后就狗撵兔子似得催着开发修改自己提交的 bug。开发都有自己的日常开发任务，尤其是在项目的初期，工作压力很大，如果将 bug 加入到开发的日常任务中会增大开发的压力，也容易对开发的工作造成混淆，好不容易想起来的思路也被突如其来的 bug 给打断了。

要想解决这个问题就必须将 bug 进行单独管理，这样不但有助于开发工作的顺利进行，对于测试来说也能更加方便对于 bug 的管理和追踪。

在记录 bug 的时候做到合理分配，轻重缓急明晰。将 bug 按照严重程度进行分级管理。一般讲 bug 分为三级：普通、重要、紧急，具体的分级可以根据实际情况来定。将紧急的 bug 列入当前的目标，并指定具体的开发人员进行修复；重要的 bug 根据产品的规划和当前的进度情况再议；普通的 bug 可以暂不考虑。

项目、目标、标签，三位一体

这样既不影响开发主线的进度，又能较好的完成 bug 的修复工作，保证现有产品的良好体验，还能减少测试与开发之间的摩擦和争吵。也保证了测试对 bug 的良好管理，后期只需要追踪 bug 的状态，将已修复的 bug 及时归档就可以了。

bug 状态的跟踪

如果做到了上述这些，测试和开发又怎么会势同水火呢？

很多时候不仅仅是把自己手头的工作做完就结束了，大家是在同一个团队为了同样的目标在努力。如果仅仅是为了更快的完成自己的工作而延误了别的小伙伴的工作，就最终将要达成的目标来说也是得不偿失的。

因此，在日常的工作中多站在对方的角度思考问题，多体谅对方，将自己能力范围内的工作做好，问题解决好，为对方营造一个舒适的解决问题的环境，对方自然将你的好看在眼里，记在心里。 即便是前世的宿孽，今世的冤家也能有情人终成眷属。