我听说开发人员说编写代码的人不应该是测试它的人。我正在寻找人们在这种情况下的经验。很多时候，我完成了自己的开发工作，然后发布给 QA 部门并将代码发回给我，因为应用程序的某些方面由于我的编码而损坏，无论我之前对其进行了多少测试QA 发布。
此板上是否有人需要遵循流程，使他们能够在发布给 QA 之前彻底测试他们的代码？
【问题讨论】：
开发人员通常从内向外工作，重点是代码：
另一方面，测试人员通常从外向内工作，专注于功能：
最终用户通常在外部相当随机地工作：
【讨论】：
开发人员应始终测试他们的代码，以确保其按预期工作。
QA 团队可以像最终用户一样进行测试，并做/发现开发人员没有想到的事情。
【讨论】：
有趣的问题。我会尝试从测试人员的角度为您提供一个很好的概述。
如果我得到一个构建，我希望代码在单元测试级别进行测试，以检查一些基础知识。这意味着当我输入一些基本的边界值检查时，它不会翻倒。例如：如果一个字段接受 0-100，那么它应该优雅地处理 101 和 -1。
这是一个简单的例子。我认为当人们说你不应该测试自己的代码时，他们指的是通常由训练有素的测试人员完成的传统测试阶段。这并不意味着它不应该在单元级别进行测试。我还提倡手动对其进行测试，即使只是为了检查它是否执行了基本操作。
当我编写代码时，我会编写单元测试、集成测试（如果可能的话），并且肯定会手动对其进行基础测试。但问题是我编写的测试代码永远不会像其他人测试它那样有效。我对代码有一些假设和想法，这可能意味着我会跳过或忽略位。我可能假设太多了。认为太多是理所当然的。想我知道代码的作用。专业测试人员会避免这些假设，因此经常会发现您可能找不到的缺陷。
优秀的测试人员还会检查边缘情况、可用性和大量有趣的领域。
这里留下了一条评论，规范可能含糊不清，因此编写测试很棘手。但作为一名测试人员，我也建议这不是让编码也变得棘手吗？
根据我的经验，将开发人员和测试人员组合在一起编写单元测试是非常值得的。这是一个惊人的景象，而且覆盖范围通常非常好。
干杯 抢..
【讨论】：
开发人员应根据给出的规范对代码进行测试。经常发生的情况是，规范可能不清楚或被误解，这是由其他做 QA 的人整理出来的，这通常意味着向开发人员提供规范的人会验证实现是否完成了它应该做的事情，并且如果不是，那就是发现不匹配并将其送回修复的时间。
【讨论】：
开发人员测试她的代码以确保代码按照开发人员认为应该执行的方式执行。
QA 团队测试代码以确保代码按照 QA 团队认为他们在文档中阅读的方式执行。
QA 团队不只是测试代码。 QA 团队测试相关方（客户、开发人员、QA、管理层等）之间沟通的有效性。
【讨论】：
re：“我听说开发人员说编写代码的人不应该是测试它的人。”
如果他们不测试它，他们怎么知道它是否有效？真正的答案是，“编写代码的人不应该是唯一测试它的人”。确实，作为开发人员，我们在自己的代码方面存在盲点（“我知道我没有接触那个代码，所以不需要测试它......”）并且需要帮助.
理想情况下，每个可测试单元都应该有一个单元测试。编写这些单元的开发人员通常会编写单元测试，但不必如此。但单元测试只是故事的一部分。应使用测试专业人员进行集成和系统级测试。
【讨论】：
以下是一些确保您的代码从以下角度工作的想法 完成一项任务。我不建议对每个人都严格执行这些 小任务，而是使用以下作为清单来给你一些想法。不同的任务需要不同的检查量。
开始实际编程之前：
编码时：
提交前：
集成服务器
发布给 QA：
其中一些可以在每次保存文件时自动完成 编辑。通常我在保存文件时至少映射一个错误检查语法 linter 来运行。
【讨论】：
我的经验法则是对每个返回值的方法进行单元测试。一旦你全部是绿色的，它就会进入质量检查。
是的，QA 可能仍会发现缺陷。毕竟，他们的工作是思考和测试你没有考虑过的情况。总的来说，我认为不太可能，当然也不常见，让代码在第一次迭代时没有问题直接通过 QA（错误修复和非常小的更改除外）。
【讨论】：
1) 是的，作为开发人员，您需要编写大量单元测试。这些将帮助您在周期的早期发现错误，然后再将其发布给您的 QA 团队。
2) 是的，作为开发团队，您还需要进行系统集成测试，以确保您的组件不会破坏其他现有功能。
【讨论】：
作为开发人员，您可以在某种程度上测试您的代码，例如：
系统测试也可以在一定程度上进行。 QA 所做的主要工作是找出用户需求并相应地检查系统。 QA 也经常检查代码，因此会发现越来越多的错误。
用户验收测试也可以由 QA 以更系统的方式进行，因为他们对用户的实际需求有所了解。据说“第三个人可以从你的代码中找出比你更多的错误”。因此，即使开发人员彻底测试了他们的代码，也必须进行 QA。
【讨论】：