当问题出现在应用程序或网站中时，对于某些人来说，第一步是指责开发人员。当然，开发人员确实编写了代码。但是现实是，错误很少是任何一个人或群体的错。有很多原因为什么不应总是将开发人员归咎于错误。开发人员的构建可能有许多不同的原因，包括：

• 模糊或不完整验收标准
• 回归（修复或新功能会导致旧代码问题 - 在我们的中了解更多信息回归测试指南）
• 基于新更新的特定设备或浏览器的问题（了解有关交叉浏览器测试）
• 匆忙的时间表敏捷过程

在这些解释和以下原因之间，最好三思而后行，然后再拖欠开发人员。

为什么不应该总是将开发人员归咎于错误

1.它适得其反。

增加额外的压力只会使虫子更有可能，因为不安全感和紧张干扰重点。当然，承担一定程度的责任通常是有帮助的（合理的）。但是，问某人为什么通过负面假设来询问它们与讯问它们之间有区别。

2.指责开发人员的错误并不总是有意义的。

总会有错误。如果事实并非如此，只有拥有可怕开发人员的团队才需要质量保证测试人员。对软件开发生命周期意味着在任何阶段构建中都期望一定程度的错误。

3.责备通过。

即使团队将所有责任归咎于开发人员，也不会留在那里。当这是团队培养的心态时，开发人员可能最终将其传递给。这可能导致责备为针对质量检查由于缺少一个错误（他们可能不知道是一项开始的要求），因此不管理Sprint时间表的项目经理以及涉及的许多其他角色。

同样，如果一个人或小组出错，他们可能会（并且应该）对解释或修复负责。但是，应根据所涉及的具体细节来处理每种情况，而不是绘制较广泛的角色或团队。

4.它可以大大延迟发布。

如果开发人员认为他们的代码必须是100％完美的，那么它就可以到达质量检查了，那么说他们可能需要几个月而不是数周才能将其删除并不夸张。质量检查的存在是有原因的，因此开发人员应该能够做到最好的第一次通过并通过它传递，因为知道QA测试人员可以识别需要修复的任何错误。当质量检查正在寻找和报告错误，开发人员可以利用额外的时间在其他新功能上取得进展。这是不应默认情况下责备开发人员的错误的主要原因之一。

5.除非您是经理，否则指责开发人员的错误不是您的位置。

例如，S QA测试人员，我们的工作是专注于错误本身。即使同事的发展努力足够问题，可以被解雇，这也是如此。这质量检查和开发人员关系当质量保证判断虫子的严重性，而不是其背后的开发人员的价值时，最好是最好的。

设置限制

避免不必要的责备并不意味着开发人员在遇到问题时不应承担责任。在某些情况下，如果某人的编程问题很严重且一致，那么让某人走开也可能是合适的。但是，在任何给定的构建中有“一些”错误不足以搭配开发人员。而且，如果您合理地接近每种情况，您可能会在表面下方找到合理的解释。

是否想与开发人员友好的质量保证测试人员合作？

别无所求 - 我们喜欢与开发人员建立良好的工作关系。看看我们质量检查测试服务了解更多。