程序员应该帮助测试人员设计测试吗？

程序员应该在设计测试方面为测试人员提供多少帮助？

我认为他们根本不应该提供帮助。我担心的是，如果他们帮助测试人员为自己的代码设计测试，他们将以自己的偏见和对该代码的盲点“感染”测试人员。

我认为这些要求应该足以提供测试人员创建测试所需的信息。如果实现的某些部分让程序员感到不安，那么我认为他们有责任实施单元测试来测试该部分，甚至运行自己的非正式系统测试来测试该部分。

不过，并非我认识的每个人都对此表示赞同（并且我在一定程度上理解了他们的一些观点）。其他人对此有何看法？文献中有没有讨论过这个问题？

我同意。程序员可以帮助测试人员了解功能规格，查找研究资源，但不应以自己关于如何进行测试的想法污染测试人员的思想。

我认为开发人员和测试人员在质量检查领域中可以和平共处。:)

更具体地说，我认为开发人员应负责第一级测试-单元测试和基本集成测试，以确保在大多数情况下，他们的东西可以工作，然后再将其交付给测试人员。

测试人员应根据完全不了解任何实施细节的要求来创建验收测试（通常称为“黑匣子测试”）。如果测试人员和开发人员对要求的理解存在差异，则应由项目经理（如果有）或确保功能设计阶段的每个人都在同一页面上来解决此问题。

我认为测试和开发都是协作的成果，因此（IMO）当然，开发人员应将测试思路提供给测试人员。我认为这根本不会感染他们或污染测试人员。当然，测试人员应该使用许多其他测试方法来增强这些测试。

我还是测试人员帮助开发人员的忠实粉丝-我在开发人员的职业生涯中曾与开发人员集思广益，并与他们一起解决了很多错误（并指出了错误和建议的修复），但我不认为曾经用测试人员的笨拙使开发人员受污。

如果您不认为它是协作的成果，那么您只需将代码从开发人员“扔到墙上”到测试……最终将导致质量降低。那是我世界的真相，但是（当然）ymmv。

我的看法是，测试我的代码不是质量检查工作。测试人员的工作是确保我的代码满足该任务的所有要求。

当我将某些信息传递给QA时，请确保他们知道我正在执行的任务，而不是我的代码细节。我从不将任何带有“骨头”错误的内容传递给质量检查人员。那浪费了我的时间，他们的时间...以及几乎每个人的时间。

在我的上一份工作中，我们从一开始就参与了质量检查。那就是需求收集会议，项目会议和设计会议。他们倾听并提出问题，而在开发人员编写代码的同时，他们也在编写测试计划。效果很好，我们发现了很多可能会遗漏的问题。

我认为您在这里误入歧途。我曾经是一名测试人员和开发人员，作为测试人员，我从开发人员关于高风险或脆弱领域的指导中受益匪浅。作为开发人员，我希望测试人员能够找到我尚未深入探讨的问题。

除非您的代码是原始污水，否则没有“污染”，这将是完全不同的原因。

需求在传达质量检查专业人员会关心的技术问题方面做得很糟糕，因为需求充其量只能详细说明业务分析人员设法解决的问题。优秀的开发人员将意识到他们的代码是围绕“快乐之路”进行优化的，并且他们想知道自己未考虑的内容。他们至少会直觉知道可能出问题的地方，以及他们希望质量检查进行调查的领域。他们还根据自己的设计知道围绕特定功能的全局风险。

在开发团队缺乏测试人员指导的情况下，我有时会采用错误的方法，该方法会生成良好的错误报告，但并未完全解决高风险的代码路径和更大的问题，而通过更好的协作可以避免这些问题与开发团队一起，运送给客户。

尽管测试人员当然不应该仅仅局限于测试开发人员所说的重要内容，但是通过了解开发人员对代码的关注点，他们不会受到损害。有时，他们可以根据对实施的了解来调整方法。只有当测试人员的目光短浅时，他们才会考虑开发人员对风险的意见。他们不会完全将开发人员认为低风险的事物拒之门外，但是他们会加大对可能产生更高客户影响的事物的投入。

QA团队可能会发现组合测试范围比系统的需求收集者或开发人员要大的区域，但他们可能不知道系统组件的脆弱性会从对设计的了解中受益或系统的实施。

以我的经验，质量保证和开发部门之间的合作产生了更高质量的产品。我永远不建议只做黑匣子交接。

作为一名测试人员，我完全不反对建议测试用例的程序员（尽管这并不意味着我只会坚持那些测试用例），也不描述实现细节。有时有人说“我认为这可能有风险，如果您对此进行了充分的测试，我真的很希望”，这确实很有帮助。了解一些实施细节有助于我运用多年的经验来选择我认为最有可能失败的测试。有时只是简短地提及就意味着一些测试突然将我的优先级列表放大。

它会弄脏我吗？我有点被程序员勤奋维护我的测试仪纯正的想法所打动，但实际上-不，这是一个神话。更多信息通常会触发更多的问题，而不是更少。我想这是一种心态-我没有发现bug，因为我很无知，我发现问题是因为我是一个持怀疑态度，不信任的人，他实在太顽固，无法完全信任任何东西。在我测试过的每个系统上，我发现我发现的问题更多，而更多的是“有趣的”问题，因此我越深入地了解它。

我想查看测试计划，并提出质量检查可能没有想到的其他测试用例。我不确定这将如何“以我自己的偏见感染测试人员”。

我发现自己处于这个奇怪的位置，之后我需要在Selenium中实现和编写测试用例，因为我们缺少QA人员。我相信测试驱动的开发将非常有帮助，但尚未在我的商店中采用。

我发现编写测试很有帮助的一件事是，在编写测试时发现了错误。我认为可以从不同角度帮助我编写更强大的代码。但是，确实可以限制测试范围。在这种情况下，QA总是可以让我们知道他们想要涵盖的内容。或者，当我们看到错误时，我们可以被动地添加更多测试。

我正在做质量检查，与大多数领域不同，知道如何使用我们的代码比学习任何编程语言要困难得多。因此，我们依靠开发人员为他们的全新Whizzbang功能提供测试案例，因为我们不知道该怎么做。无论如何，与对新功能的原始测试相比，质量检查问题更容易引起回归和问题。在任何情况下，如果结果是复杂的计算，都很难知道什么是正确的答案，什么是错误的答案，或者即使异常终止是好事还是坏事。

无论如何，如果开发人员诚实的话，他可能知道他的一些婴儿漏洞。他可能知道什么参数值，他必须选择不同的算法或表查找中的域或其他内容。知道这一点，如果他对严格的测试有诚意，那么他应该能够生成涵盖许多代码的合理大小的测试套件。