报Bug的顺序

也许有人从没有考虑这个问题，觉得测试人员对于报Bug没有顺序而言，发现一个报一个。甚至坚持着这个原则：“宁可误报三千，不可漏报一个”，积极地汇报着自己发现的所有Bug。结果，慢慢地就发现Dev对自己报的Bug失去了灵敏性，往往自己报的一个Bug，即便有工具的提示也会被开发人员不断地忽略或者推迟。

的确，这是一件令人沮丧的事情。作为测试人员，汇报Bug是自己工作成果之一，在大多数公司甚至就是主要成果。一旦自己的成果被别人忽视，引来的就是测试人员成就感的丧失，继而影响测试的情绪，从而带来测试效率低下的后果。

这个问题其实还是非常普遍的。据我观察，身边很多测试人员(包括刚从事测试工作的我)都犯过或者正犯着这个同样的错误。这个问题的出现很难过多地把责任放在Dev身上，事实上测试人员更需要担负多的责任。

出现这个问题的原因主要是测试人员没有很好的把握Bug的严重性及优先性，没有把握好Dev的心理需求。举例来说，单词拼写错误的严重性比程序在某些情况下功能散失的严重性要轻的多，但是往往可能更好的被发现。可能有人喜欢在测试前几个周期里就喜欢大量报道这类问题，从而让Dev接受类似"服务拒绝”攻击似地的Bug报道。而开发人员在测试前期一般对自己代码不具有充分信心，此时更多地是希望测试人员从功能性上提供质量反馈。当然，大量的拼写错误式的Bug列表不断让开发人员出现“审美疲劳”，对你报的问题逐渐不敏感起来也就不奇怪了。更严重的问题是，大量这类问题的汇报同时也在消费着自己的信誉，给开发人员一种印象：这人根本就找不到问题，只会抓些皮毛的问题扔给我们，让我们忽略他吧。于是你就在不知不觉中，"努力地"把自己扔进了黑名单。

可是作为质量守卫者的测试人员是不应该把这类问题留给用户的。按照上面所说，我们该怎么弄呢？记住，我的标题叫“顺序”，就暗示了我对Bug汇报持有的观点是：这些Bug是一定要给开发人员接受的，不过不在最初开发人员正渴望修改功能方面问题的时候，而是按照一定的顺序提交给他们。

我推荐一种做法：针对所有你觉得是问题，但又不至于严重影响程序质量或者项目进度的一些“小”问题，把它用你的私人备忘录记录下来，而把功夫主要花在功能、性能等方面的质量反馈上。当你报了几个大问题后，可以“喂”一些小的Bug给开发人员；或者在你得知开发人员在修改了几个大问题后出现空档时报他几个小问题，让他们调剂一下。在我的日常工作中，甚至我会把一些极小的问题私底下告知开发人员，让他们纠正——当然我会暗地里跟踪这些问题的修改进程的。一方面开发人员觉得Bug管理系统里自己的Bug会少些，而或多或少对你有些私下交情——比方说更快的反馈你报Bug的修改进度情况或者在讨论中更多的维护你的观点；另一方面，你并没有失去什么，不是么，你的问题也没有被落下。测试人员守卫质量的职责你并没有放弃，你在开发人员心中也具有了更多的信誉。这大概就是Win-Win吧。

扯了这么多，其实最大的总结就是测试不仅是个技术活，还是一个极具心理学挑战的工作。你不仅要和代码打交道，还得和一批优秀的又经常自认不凡到甚至有些自负的开发人员打交道，你得学会在不断提高自己技术的同时还提高自己和他们打交道的技巧。相信你在自己的工作中不断体会，自然会得到自己的一套方法。