图1说明了系统人员是软件开发和软件测试的基础和核心。通过系统人员将产品的用户需求转化为详细的需求规格说明。在需求规格说明基线化后，软件人员以此作为基础进行系统概要设计和详细设计，而测试人员根据需求规格说明来进行软件测试策略和详细测试用例的设计。同时，软件人员和软件测试人员都需要和系统人员紧密合作和交流，将各个阶段的开发活动和测试活动得到的信息反馈给系统人员，来完善和优化系统需求规格说明。按照这样角色和职责的定义，假如开发人员和测试人员针对某个产品的表形行为有分歧的时候，可以通过系统人员来做最后的决定。通过软件开发过程控制和管理，开发人员和测试人员就可以较好的避免纠缠“是缺陷还是功能点”此类问题，从而提高我们的测试效率，同时也可以更好的实现项目利益相关者之间的沟通。
4）测试人员的角色
开发人员拒绝测试人员提交的缺陷的第四个可能理由是：产品的需求规格中并没有这样要求，需求规格中的功能和特性已经实现了。
引起这个问题的原因主要是开发人员对测试人员角色和职责的定位不清楚。假如开发人员并不能很好的理解测试人员的工作，那么开发人员和测试人员之间在缺陷方面的沟通也会存在一些问题。那么，测试人员的角色和职责应该是什么呢？我们认为测试应该是贯穿于整个软件开发生命周期，而不仅仅只是代码阶段之后的测试执行活动。这里引入Verification和Validation两个概念：
● 验证（Verification）：通过检查和提供客观证据来证实指定的需求是否满足。也就是说，输入与输出之间的比较。也就是说，是检验软件是否已正确地实现了产品规格所定义的系统功能和特性，即“Are you building the product right”。
● 确认（Validation）：通过检查和提供客观证据来证实特定功能或应用是否已经实现。在确认时，应考虑使用和应用的条件范围要远远大于输入时确定的范围。一般是由客户或代表客户的人执行。也就是说，是确认所开发的软件是否满足用户真正需求的活动，即“Are you building the right product”。
根据Verification和Validation两个概念，我们可以看到，测试人员除了要验证产品是否正确实现了需求规格说明之外，他还需要站在客户的角度，分析产品是否真的是客户所要求的。因此，测试过程中，测试人员除了报告功能性的缺陷之外，特别需要注意一些非功能的特性，特别是用户所关注而需求规格中可能并没有明确定义的要求，例如：产品是否容易使用，图形界面是否布局合理等。
前面分别谈了开发人员拒绝修复测试人员提交的缺陷4个主要原因，以及根据笔者的经验提出的一些建议。当然，测试过程中我们肯定还会碰到其他的一些原因，导致开发人员不愿意修复某些缺陷。不管是什么原因，都需要我们测试人员具备良好的沟通能力、规范严谨的缺陷报告编写能力，以及通过良好的合作让开发人员更好的理解测试工作，从而达到更好更快的发现和修复缺陷，实现高质量产品的及时发布。
