一般公司发展到一定程度，均要进行开发质量的考核。
考核的指标一般有：bug数，千行代码bug率，低级bug率，bug关闭时间，bug重开次数，bug重开率等。
大部分是关于bug的，在这种时候，当bug真的和开发绩效挂钩，同时暗示着也要和测试绩效挂钩的时候，我们到底该如何正确的看待bug，如何摆正自己对待bug的心态。
开始质量考核前，开发与测试不存在严格的厉害关系，我们都是为质量负责的人，开发通过代码设计与自测来提供基本服务质量，QA通过接口测试模块测试系统测试等测试手段来最终保证服务质量。大家是同一条船上的蚂蚱，对一个或几个服务质量负责。这是友好共生的美好画面。
但是，开始质量考核后，开发与QA突然站到了对立面，开发认为QA你这样提这么多bug影响了我的绩效，QA认为bug数本身我也有绩效啊，不给你提我的绩效怎么办。
解决这个异常画风，要从三个方面考虑：
1.提供方便合理的回滚或废弃机制，所有异常或错误数据均可以回滚或废弃，并且不计入开发和QA绩效中。
很多时候由于开发与QA角度不同理解力不同，经常会出现一些无效bug，包括因为环境问题/需求问题/技术实现问题等产生的无效bug，这种无效bug一定要支持开发关闭。并且当流转到QA那里时，QA可以对此bug二次确认，决定关闭或者重新打开。
2.与绩效挂钩但不严格挂钩
一个开发者能力的好坏，代码质量是其一部分。对开发能力的评估，决不能仅仅从质量维度出发，其他的如需求维度、服务稳定性维度统统都要考虑。所以要点是制定各个维度合理的权重，在核心指标上加大比例，在非核心指标上缩小比例。
同样，直接用bug数来评判QA能力也是愚蠢的。QA不等于测试，但bug数只体现了测试部分。
3.开发者的心态
要知道大家都是在工作，所有的手段方法都是在为质量负责。QA提bug是，开发解bug也是。
我们遵循这个流程来做事情，是在工作，不存在个人恩怨和情仇。
同样的，开发者想要提高自己的绩效，不能通过围堵QA提bug来做，这是一种风险很高的事情，影响了QA测试，其实是影响服务质量的，出故障还是要自己背锅。
正确的做法是引导QA测试，介绍自己的设计编码思路和方法，帮助其提高测试覆盖率，最大限度降低风险。
同时QA不要把提出bug来当做一件很快乐高兴值得骄傲的事情，本职工作并不值得炫耀。千万不要拿着bug嘲讽开发。
另外开发与QA要进行良好的沟通与互动，对无效bug直接关闭不用往复多次开关。
最后，bug只是开发与QA协同工作为质量负责下的一个产物，不应过分看重与在乎。