为什么要让/不让开发人员测试自己的作品

我想收集一些争论，为什么让开发人员在产品投入生产前的最后一步测试自己的工作是一个坏主意，因为不幸的是，我的工作地点有时会这样做（这是最后一次出现，这种说法归结为大多数人太忙于其他事情，而又没有时间让另一个人熟悉程序的那部分-这是非常专业的软件）。

在这种情况下有测试计划（尽管并非总是如此），但我非常赞成让一个没有进行测试变更的人实际进行最终测试。因此，我想问您能否为我提供一个良好而可靠的论点清单，以便下次讨论时可以提出。或者提供反驳，以防万一您认为这很好，尤其是当有正式的测试用例要测试时。

正如其他人（和您自己）所指出的那样，开发人员应该对自己的代码进行单元测试。但是，此后，任何不重要的产品也应由独立人员（质量检查部门和/或客户本人）进行测试。

开发人员通常以“如何进行这项工作？”的开发人员心态工作。。一个好的测试人员正在考虑“如何打破这一点？” -截然不同的心态。单元测试和TDD确实教会开发人员在一定程度上更换了帽子，但是您不应该依赖它。而且，正如其他人指出的那样，总是存在对需求的误解。因此，最终验收测试应由尽可能靠近客户的人进行。

开发人员知道他们的代码是如何工作的，并将养成根据这种知识测试他们的代码的习惯。

开发人员会发现很难将自己从“它如何工作”的思维模式中移出，而不是“应该如何工作”。

因此，最好是让一个具有高度客观性的人来测试程序，即QA或测试工程师

测试人员测试打破，简单。 需要使用这种类型的偏见才能真正找出演出的制胜者。

开发人员必须测试他们的工作。这是一个隐含的责任。

我假设您没有专门根据您的陈述进行测试的团队。但是，拥有一支专门用于测试的团队确实会有所帮助，因为开发人员倾向于按照编码方式对其代码进行测试。这并不意味着一旦您拥有某种质量保证团队，您就已经可以将测试作为开发人员的责任。

开发人员通常使用带有大孔的网络来捕获错误。结果，较小的错误得以逃脱。

因为开发人员不擅长尝试破坏自己的代码。他们的想法只是遵循数据输入和与应用程序交互的正确路径。许多错误是像正常人一样与系统进行交互的结果。开发人员不是普通用户。他们是专业用户。

有几个很好的理由要有一个专门的测试团队。首先，如上所述，开发人员非常擅长测试其代码是否有效，但并没有破坏代码。

而且，正如您所说，开发人员知道他们编写的内容，而测试团队知道应该编写的内容。有时，这两个概念不匹配。测试团队的工作之一是确保软件符合要求。在许多情况下，开发人员只非常了解系统的某些部分，但是质量检查团队却了解整个过程。

这导致了下一个原因，测试团队将进行完整的集成测试。您刚刚编写的代码本身可以很好地工作，但是可能破坏您不知道的其他功能。

在没有QA团队的情况下，我可以告诉您我100％地赞赏他们所做的工作，并且会说他们是软件团队的重要组成部分。当您有QA小组时，它使发布代码变得更加容易，因为您知道该代码已经过全面测试，这意味着您将减少凌晨3点的呼叫。

开发人员应该对自己的代码进行单元测试。

独立测试人员不仅测试破坏，而且测试开发人员在编码时所做的未陈述和不确定的假设。

我希望开发人员在提交任何更改之前先进行一些初始测试，并对代码工作感到满意。然后，我希望开发人员将他们所拥有的任何特定“白盒”知识引入测试用例中。例如，详细说明代码可能受到影响的任何其他区域。

开发人员测试他们自己的代码的主要反对意见是您仅测试一个观点。开发人员已阅读并解释了规范。希望规范是清晰，完整和明确的，但并非总是如此。开发人员可能对规范有误解。如果他们测试自己的代码，则不会被捕获，因为他们会发现函数按预期运行。

不同的人还会倾向于以不同的方式使用产品，并因此通过代码采用不同的路线。开发人员将确保该代码适用于他们，但可能没有考虑其他测试人员可能会发现的极端情况。

开发人员应测试自己的工作。让开发人员将未经测试的工作推向质量检查团队或其开发人员同事，这确实是一个坏主意。这浪费了开发人员和测试人员的时间，并且破坏了关系。

但是，这并不总是足够的。开发人员可能会沿着整个系统走一条快乐的路，或者对他们在整个开发过程中一再暴露的某些特质视而不见。

另一个要点是，规范和部署之间可以有许多层次的通信。这可能会导致中国耳语对最终部署的影响。最好是由定义需求或错误报告的人员以所需的方式进行测试。

作为开发人员，您应对自己的代码负责，应该对其进行测试。Does the feature work as expected?如果答案是肯定的，那么您就完成了。

您为什么不做测试用例？

1. 您是主观的，因为发现的错误是由您（或您的同事）编写的。
2. 你太昂贵，为公司运行情况的测试。（我希望）。

通常，除某些特殊情况外，在大多数情况下，开发人员不会使用代码。因此，升级到生产系统之前的最后一个测试步骤应该是用户验收测试，即UAT。通常，他们[应该]对他们期望该软件包正在做的事情更加熟悉。通常，他们更擅长于打破那些每天都不使用它的人所不熟悉的入门流程。

您的项目计划是否不适合用户测试？如果让用户对其进行测试，则可能会比实施后更早地发现错误，对我而言这并不是一件坏事。

开发人员不应测试自己的代码，因为这类似于判断您自己孩子的艺术。无论哪种方式，它看起来都会很漂亮，您确实需要专业人士指出缺陷。另一方面，单元测试类似于确保您的孩子不尝试用铅绘画。

如果你们真的不想雇用QA，请让开发人员为其他开发人员编写测试代码。这是一个很好的第一步-很快您将看到开发人员要求质量保证资源，因为除了CR之外，他们的大部分时间都花在测试其他人的代码上以解决问题。

这不仅是开发人员保护自己的代码，如果他们没有意识到一个特定的案例，或者在开发某些东西时错误地解释了规范，那么他们在测试代码时就会错过这些案例。

测试的技术和技能也非常不同。

测试团队的大多数测试都是功能性的（产品按照规范运行）和黑盒（测试团队不会看到应用程序的内部工作）。功能测试人员不需要关注事物的工作方式，而只需要关注它们是否起作用。

根据我的经验，至少在我的小型组织中，最终用户需要进行测试。我们获得的几乎每个项目，都无法提供所有需要的信息，并且总是遗漏某些细节。开发人员始终处于测试劣势，因为他不知道如何完成用户的工作，因此尽管他知道软件可以根据给出的信息工作，但他不知道该软件是否会对最终用户有所帮助做好他们的工作。

开发人员误读和误解了需求，而对需求负责的人通常无法指定关键事项。如果除开发人员之外没有人进行测试，那么在上线之前没有人会发现这些断开连接。当开发人员进行测试时，他们对应该如何工作了解得太多，不要尝试用户可能会尝试的愚蠢事情。开发人员还根据自己对需求的解释来编写测试，而这通常并不是真正的含义。因此测试通过了，但是没有满足要求。当您进行不同的人员测试时，该人员可能对需求有不同的想法，并且您经常会发现在两个不同的人对需求的理解上，招聘的表达很差的地方。在测试中发现这一点比上线后要好得多。

开发人员应该进行初始测试，以便我们可以根据自己的要求，知道编码的代码将按预期的工作方式工作。因此，我们对所编写的代码进行了常规测试以及编写了单元测试。

下一步是QA的工作，以找出开发人员在编写代码时看不到的内容。开发人员以更高的层次进行思考，但用户可能不会以相同的层次进行思考。当开发人员测试自己的作品并必须在文本框中输入一些文本时，他可能总是输入完整的字符串，以为用户也可以这样做。可能是用户也可以这样做，但是当他在文本中输入特殊字符（例如％＆$ ^）并破坏了应用程序时，最终用户看起来并不好，这是随机的。开发人员不能也不会考虑可能发生的所有可能性，因为他没有受过这种思考的训练。当涉及到QA（测试人员）时，他们总是在考虑用户可能会怎么做才能破坏此应用程序并尝试书中的每一个愚蠢的事情，而不是用户是愚蠢的，但我们不应留任何机会。

现在，我们还必须了解，通常同时完成多个任务，并且两者都将投入生产。开发人员只能测试他的作品，并认为这很好，但是需要对所有被推送的作品进行整体回归测试，并发现两个不同作品的组合可能会破坏应用程序，并且确实也不好看。我们还必须考虑负载测试方案以及测试人员更熟悉的其他方面。

最后，我们必须通过UAT（用户接受测试），看看我们所做的工作是否符合预期。通常，尽管要求是通过BA获得的，但最终人员可能并不完全知道其外观，并且他/她可能认为这不是他们期望的样子，或者他们可能想要添加其他东西以使其看起来更好，或者由于某些原因而放弃了产品。他们认为整个作品将无法与现有功能结合使用。

如上所述，这些功能非常重要，不能由开发人员单独完成，而且对于应用程序正常运行是绝对必要的。管理层可以说这是一个保守的方法，但这是更好的方法。我们可以对上述内容进行一些调整，但不能整体避免。

上面的评论提出了很多观点。

前面没有提到的另一项是，具有单独的单独测试代码可作为对要求的额外检查，以及系统是否正确实施了这些要求。

需求和文档并不完美，通常实现是开发人员对需求进行解释的结果。

当测试由一个单独的人完成时，他们在创建测试计划和执行测试时也会提供自己对需求的解释。

当测试活动独立于开发活动而完成时，并且两者的“同意”输出都提供了额外的确认，即系统正确且确实符合需求的初衷。

程序员在测试时，将看到一个标记为“数量”的文本框，并输入“ 1”。然后，经验丰富的程序员将使用值“ 2”进行后续测试。

用户将看到一个标签为“ Quantity”的文本框，并输入“ ~~ unicorns ROX !!! ~~”。有经验的用户也可以尝试“ -12 1/2”。

希望有一个测试人员在某个地方，以警告程序员用户在进行这些操作时将会经历的事情。

原因之一是因为开发人员过于接近自己的代码。他们知道这是怪癖，这不是什么奇怪的行为。他们倾向于围绕自己熟悉的小特质进行测试。他们对此不够客观。测试团队将其视为黑匣子。他们编写了数十个或数百个测试用例的矩阵，并有条不紊地遍历它们以查看代码将做什么。通常，他们会提出开发团队梦dream以求的方案。

另一个原因是时间。对于分阶段构建的大型项目，开发团队将构建阶段1。然后，测试人员将在构建阶段2和修复阶段1的缺陷时对其进行测试。这对于所有阶段都是如此，因此要测试的阶段是之前构建的阶段。

我想收集一些论点，以说明为什么让开发人员在测试投入生产前的最后一步来测试自己的工作是一个坏主意，因为不幸的是，我的工作地点有时会这样做（这是最后一次出现，这种说法归结为大多数人太忙于其他事情，而又没有时间让另一个人熟悉程序的那部分-这是非常专业的软件）。

测试对于开发人员来说不是可选的。开发人员必须测试他编写的代码。他还能如何确定任务已成功完成？您要么必须编写某种自动化测试（单元测试），要么手动执行“检查计算机是否在执行我想要的工作”（通过使用GUI，在命令行上调用命令或执行其他操作）。

之后要测试的所有内容都是“仅”其他人（同事，QA等）的附加测试。开发人员无法进行直接测试。每个告诉我开发人员不必测试（甚至不允许）开发人员编写的代码/功能的人，对软件的开发方式都是零了解。

无论您是否喜欢，它都会由不熟悉该代码的人进行测试。问题是您是否希望某人成为您的客户。

好问题。在您的情况下，有时会存在测试用例，并且该软件似乎过于复杂，以至于使新手无法快速了解产品。您还说执行的测试是生产前的最终测试

开发人员可以进行最终测试的理由

• 还有其他足够的测试范围...存在单元测试，已经存在并使用了集成测试环境，已经执行过UI测试，探索性测试等。因此，最终测试比最终的“跑过，匆匆处理”
• 存在由专业SQA /测试人员编写的一组测试用例，某人（开发人员）可以/需要明确地遵循
• 否则，功能/产品/模块发生故障的风险已降低到较低的水平（让专业人员测试高风险区域，而“新手”测试较低的风险）
• 业务情况的现实情况是，发布具有潜在缺陷的产品比延迟发布更好
• 所讨论的开发人员实际上也是一名非常合格的测试人员，并且能够在头脑上进行角色更改
• 更改是由开发人员在客户的站点因系统离线而关闭或以其他方式导致收入损失时在现场进行的错误修复（此补丁将带回办公室并以受控版本ASAP进行测试/发布） ）

开发人员不应进行测试的原因

• 还要别的吗

总的来说，您似乎正朝正确的解决方案进发-让SQA专家生成测试用例...

注意：我通常赞成让开发人员进行测试，但是我要确保第一个要点存在。

作为人类，人类往往会遭受认知偏差的困扰-在这两种几乎相同的情况下，他们的判断会有所不同，这仅仅是因为一些事情发生了变化-我在8年的开发中注意到的一件事是，当开发人员与同事编写的代码相对，测试人员面对的是测试自己的代码，而对自己的代码执行的测试质量较差。

这并不是说开发人员直接有过错-他/她的大脑将使用他们编写的偏见来强调他们相信其权利的事实，并且只会执行基本检查，而不是开发人员正在查看别人的代码，将会进行更彻底的检查。

那里有成千上万的示例，其中已经采取了防止认知偏见或通常称为“人为因素”的程序，例如空中交通管制中的计算机系统，以防止两架不同的飞机在同一时间占据同一空域时间，到医疗程序到位，因此不止一名医生必须做出诊断。

IT业逐渐趋向于更加专业的态度，并制定了相应的程序以防止对您自己的代码进行测试，这是时候了。

• 每个人都应该测试-开发人员测试代码，质量检查人员的测试功能，市场营销测试消息。这样，每个人在测试方面都拥有相同的理念和语言，这是成功的一半。

• 测试是例行维护，我通常使用类比进行比较。例如汽车换油类比。您永远不需要“换油”。但是您还是要定期这样做。刷牙也一样。每天维护它们是有原因的-它们不会在“今天”中断，这完全取决于明天和未来的日子并进行投资。

• 每个人都应该承担测试的责任。质量检查团队很重要，但是进行“测试”是只有质量检查团队才能做到的事情，因此它是一项“单独的”活动，没有集成到产品开发和工作流程中，这不是一件好事。

• 当生产中断时，请执行以下两项操作：

  1. 首先说“嗯，我们对此有一个测试 ”。
  2. 进行任何修复均应包括针对该问题的测试，然后再进行修复。

在我的公司，我们构建了一些非常复杂的财务应用程序。我们的总体政策是，开发人员应确保不会出现技术错误。基本上，在给定用户资源的情况下，尽一切可能破坏它。当找不到运行时错误时，请将其转发给BA进行测试。我们有一些开发人员在测试业务需求时迷失了方向，以至精疲力尽，但这仅仅是因为所有测试都不是他们的责任。除非存在明显可见的明显错误，否则我们会将其转发给获得报酬的人员以了解输出。此外，用户应在验证结果中扮演真正的角色。零售商店的业务员不会为您试穿衣服，它们只会为您提供“技术细节”方面的帮助，例如找到合适尺寸的衣服。

一个问题是开发人员没有动力去破坏自己的代码-很少有人愿意寻找自己作品中的缺陷或愿意犯错误。拥有一个单独的团队有助于确保一切顺利。

除其他原因外，质量保证角色至关重要，以便有人可以检查开发人员是否了解要求。开发人员无法自己进行检查，因为如果他们认为自己被误解了，则需要澄清。