测试做久，才发现开发方会在价钱、缺陷等级数量上总会有讨价还价的现象。由于我们公司比较特殊，都是帮公司公司内部做测试，可能有些测试公司，只是做测试，外包别人的项目做测试。像测试外包公司，在价钱方面应该是商量好的，钱大家觉的合适就做，不行就不做。但我们公司，给内部做测试，就算测试部门没有盈利，还是要为开发方服务的。不知道其他公司是什么情况。
我们公司，在每周五会开PM会议，测试方回提报发现的缺陷数量和缺陷等级。对应严重等级、次严重等级，高层主管会对开发PM提出“严厉的要求”。所以今天在我们办公室上演了一场开发方和测试PM讨论缺陷个数的戏幕。这个专案是在星期一测试方结案的。到星期五了， 开发方PM觉的他们的缺陷数量太多了，在高层主管面前不好，说明白一点就是会影响他们的绩效表现和年终奖。在他们明显的对话中，感觉到开发方有扯皮的现象，目的就有一个希望测试PM少报几个缺陷。
他主要的说辞是：1、他不懂得用MANTIS， 不知道如何关闭缺陷， 2、现在才意识到缺陷数量会影响他们的绩效，（所以到星期五才来说明这个问题，要求测试部门更改测试报告） 3、觉的缺陷数量太多，有好几个缺陷问题是由于一个多线程争用资源而导致的缺陷，所以这几个缺陷应该是算做一个缺陷。（为何现在才意识到，如果当初提报缺陷的时候，早些找出原因所在，不就可以和QCM沟通了。）
可能由于主管和开发PM比较熟悉，也就把测试报告改了，抱的态度是：反正发现的缺陷多少与工资多少无关。
在他们的谈话中，明显感觉到开发之前没有关注这个问题，或许是他们那时还不知道事情的严重性，要是他早些知道这会影响他们绩效，应该会在提报缺陷的时候就给出足够的关注程度的。当然测试方也有问题，还没有能力准确定位到引起缺陷的代码段。这是测试方需要能力提高的地方。
个人感觉，在这次谈话中，测试方做的比较好的地方如下：
1、在测试前期， 有向开发方确认需要测试的模块。
2、在提报缺陷的时候，有按照系统的不同版本，总结和提报缺陷。
这样在开发方来讨价还价的时候，可以明确职责。发现有一点需要改善：在开发方（特别是第一次与测试方打交道的新手）应该教会他们使用缺陷工具，告诉他们测试流程，主要告诉他们：在什么情况下，关闭缺陷，什么时候下更改缺陷状态。最好是用缺陷管理工具管理缺陷。
注：什么情况下才能关闭缺陷？？？？
答：1、当测试组长和开发PM讨论后，这个缺陷不是缺陷，提报的缺陷可以关闭。
2、提报一个缺陷，开发确认为缺陷，之后将缺陷状态更改为‘已解决’，测试人员再次验证次缺陷是否真正解决，如果解决，则关闭此缺陷。
而开发方如果对缺陷有异议，应该在提报缺陷的时候，就提出来，之后就会有一次缺陷评审的过程。开发方同样需要对测试提报缺陷，发现缺陷后如何处理的流程有所了解。而不是到缺陷数量与绩效等级挂钩时，才上心。
总结：提前知道做一件事情的流程，在风险没有出现之前，想到管理风险的手段。
总之一句话，提前做好准备，保持积极的态度。
来源：https://www.cnblogs.com/Sophia_Wyy/archive/2011/01/07/1930311.html