程序员是不好的测试员吗？

我知道这听起来很像已经提出的其他问题，但实际上略有不同。似乎通常认为程序员并不擅长于测试应用程序。例如：

Joel谈软件- 没有测试人员的前五（错误）原因（强调我的意思）

甚至不要想告诉大学CS毕业生他们可以为您工作，但是“每个人都必须在QA工作一段时间，然后再进行编码”。我已经看到了很多。程序员不能成为优秀的测试人员，并且您将失去一个优秀的程序员，而后者很难被替换。

在这个问题中，最受欢迎的答案之一是（再次强调）：

开发人员可以成为测试人员，但他们不应该成为测试人员。开发人员倾向于无意/无意识地避免以可能破坏应用程序的方式使用该应用程序。那是因为他们编写了它，并且主要以应使用的方式对其进行了测试。

所以问题是程序员不好测试吗？有哪些证据或论点支持这一结论？程序员是否只擅长测试自己的代码？有没有证据表明程序员实际上擅长测试？

我所说的“测试”是什么意思？我并不是说单元测试或任何被软件团队用来编写软件的方法论的一部分。我的意思是在构建代码并将其部署到软件团队称为“测试环境”的任何位置之后使用的某种质量保证方法。

这个问题似乎是在专门询问系统测试，所以这就是我在整个答案中所指的内容。

我认为，要选择执行测试的坏人与实际上不擅长测试之间有一个重要的区别。

为什么程序员不擅长测试：

• 如果您已经编写了代码，您（应该）已经想出了尽可能多的方法来解决问题，并加以解决。
• 如果发现一个特别小的漏洞意味着您必须去修复它，那么您可能会讨厌在一个代码库中，那将无济于事。

为什么程序员擅长测试：

• 程序员倾向于逻辑思维，善于系统地工作。
• 经验丰富的程序员将非常擅长快速识别边缘情况，因此提出了有用的测试。（如果有一个正式的测试过程，那么所有这些情况中的大多数应该已经在系统测试之前就已经被识别和测试了。）
• 程序员非常擅长确保将所有有用的信息都放入错误报告中。

为什么程序员是不良测试人员：

• 编程人员比测试人员昂贵（在大多数情况下）。
• 思路根本不同：“构建（运行中的）产品”与“此产品不会出现任何（未知）错误”。
• 测试人员通常会更有效率-即在相同的时间内执行更多测试。
• 程序员专门从事编程。质量检查专业人员专注于测试。

我认为程序员不好测试自己的代码。

我们希望相信我们的代码可以根据要求完美地工作并对其进行测试。在我自己的地方，我们测试我们自己的代码，然后在发布到实际测试周期之前先测试彼此的代码，这样，不仅通过测试我们自己的代码，还捕获了更多的错误。

程序员绝对是测试系统某些部分的合适人选-在某些地方，他们是唯一能够有效执行该程序的人。

程序员最不擅长测试的地方是整个“像普通用户一样使用UI”位-他们不是普通用户，行为也不像他们。例如：

• 程序员往往善于正确输入文本。我看到一个很常见的问题是前导空格或尾随空格。大多数人似乎并不喜欢它们，但是优秀的程序员可能会虔诚地使自己的字符串成为正确的字符串而没有多余的空格。
• 程序员往往是键盘手，他们利用标签和其他快捷方式来加快工作速度。普通用户倾向于在字段之间抓住鼠标。
• 程序员倾向于理解系统在告诉他们什么，而不是忽略错误消息并仅单击OK。

因此，普通用户会做很多程序员不会做的事情。您不能完全依靠开发团队来进行UAT。

在技​​术级别（单元测试，集成测试，回归测试），程序员可能是唯一合格的测试人员，因为这类测试是可自动化的，因此应该是自动化的，这是需要编程的东西。

但是我不认为这是您在说的，我很确定这也不是Joel Spolsky的意思-剩下的部分是实际动手手动测试：将需求文档和功能规范转变为测试脚本，然后针对成品精心执行此脚本。

成为一名优秀的测试人员需要具备与成为一名优秀程序员所需要的正交性。有一些重叠之处-您必须能够进行分析性思考，通常需要与计算机保持一定的亲和力-除此之外，测试人员的技能大不相同。这本身并不意味着您可以同时拥有这两种技能，实际上，很多人可能都具备。但是，要成为一名真正的优秀程序员，就需要一定的懒惰（希望将您的琐事自动化），而一个真正优秀的测试人员则需要持久性（检查所有三千个表单字段是否存在不一致），结果，即使是那些确实有成为测试人员通常会讨厌的想法。

然后是选择性的偏见：即使已经很少地参与一个项目的程序员，也已经对代码库有一些内在的知识，并且从最终用户的角度来看，将很难以空白的心态来处理它。 。它甚至不必是明确的，如“我知道此按钮有效，因此我只记录'pass'”；它可能更加微妙，而这些微妙的影响可能导致在测试中遗漏关键的边缘情况。

根据我的经验，是的，程序员是糟糕的测试人员。我经常看到别人和我自己走，“呵呵，但是我在办理登机手续之前就对它进行了测试！” 当测试人员面对时，会在您面前重现错误。

为什么？好吧，我不确定为什么会这样，但也许是因为我们希望看到这些东西起作用。或者，我们只想开始测试该功能。

无论如何，测试不是我们学到的技能，我们也不擅长编程，因为我们擅长破坏功能。同样，我们可能不知道如何进行适当的测试计划或QA所做的所有其他工作。我们再没有资格胜任测试人员的工作，而胜任测试人员有资格实施新的3d渲染管线。

就像这个问题一样，测试并不意味着自动化，而是实际上使用该程序进行测试。

有几个测试级别。“低级”测试可以并且必须由开发人员完成。我认为在单位testig。

另一方面，“高级”测试完全是另一回事。总的来说，我认为开发人员是不好的测试者，并不是因为他们错过了技能，而是因为很难改变思维方式和工作方式。

我曾经尝试尽可能多地测试我的代码，但是在测试人员进行至少10分钟的测试后，出现了一些需要考虑的错误或增强功能。这意味着测试您创建的内容是一项艰巨的工作。您知道要单击的位置，您要单击的时间，业务逻辑，您可能知道数据的持久存储方式。你是神，你永远不会倒下。

您是什么意思的测试？如果您指的是全面而详尽的测试，那么我可以看到一些说出是的理由，尽管我怀疑如果将所有可能的输入组合视为此类测试的要求，那么大多数人将不在这一类别。

我可以肯定的是，设计软件的开发人员在处理代码要处理的内容时可能会有洞察力，而忽略了一些可能尚未考虑的边界情况。例如，如果我构建一个使用数字n的Web表单，然后在屏幕上从1到n打印，我可能会错过一些特殊情况，例如如果未输入任何内容或诸如e或pi的非自然数。在这些情况下，该程序应该做什么？

测试驱动开发将是一种开发方法的示例，该方法将测试置于另一种角度，这可能会在这里给出另一种观点。

程序员在编写代码之前定义测试时可以很好地定义测试。通过实践，他们会变得更好。

但是，在为他们编写的代码定义测试时，它们做得不好。他们在测试中的盲点与编写代码时相同。

使用程序员进行手动测试只是愚蠢的。手动测试本身就很愚蠢。使程序员做到这一点非常愚蠢。它很昂贵，并且赶走了合格的程序员。

我特别看到开发者失败的一种测试类型是测试是否满足要求。开发人员认为需求中的内容意味着什么，而测试人员认为这意味着的东西通常是两个完全不同的东西。

我可以想到最近一次有人要求develoepr进行delta导出，而开发人员认为这意味着获得曾经未发送过的所有记录，而测试人员则认为这意味着获得任何新记录和任何更改。他们不得不回到客户那里来找出谁是正确的。我编写了代码，对其进行了审查，并做出了相同的假设，即开发人员对该要求做了规定。因为从逻辑上讲，如果您想包括更新，那么您会提到它们。而且我通常善于发现那些模棱两可的东西，因为我曾经是事物的用户端。

因此其他进行测试的开发人员往往会做出许多相同的假设，因为他们也会做出某些假设，例如“嗯，如果他们指的是X副Y，他们将有更多的细节，因为在我可以做之前，有太多细节需要回答但是需求编写者却不这么认为，因此，像需求编写者那样思考的人需要测试开发人员的假设，而不是开发人员的人则更能发现问题。