质量保证人员应该编写一些生产代码吗？开发人员应该做一些质量保证吗？

Question

在足够小的组织中，是否应该有完全独立的QA和Dev角色，或者每个角色是否需要一段时间（例如，每周1天）扮演另一方的角色？

我不是在谈论单元测试。我说的是关注系统的质量保证也会提供一些生产代码，而开发人员花费一些时间来分析和测试系统的一个独立部分。

在我看来，这种杂耍可能有意义，因为QA可以更好地理解系统中的个人利益，而开发人员可以更好地理解质量和测试问题，超越单元测试。但我相信也有理由反对它......

Answer 1

需要考虑的一些要点：

• 据推测，你雇佣了你的开发人员，因为他们擅长编写代码，而你的测试人员则因为他们擅长QA。从商业角度来看，支付他们做彼此的工作是否有意义？
• 如果您的测试人员对代码了解得太多，他们会发展盲点吗？
• 同样，你的开发人员真的可以成为有效的测试人员吗？他们对应用程序有深入的了解吗？

Answer 2

作为一名QA人，我发现这个想法很有趣。有机会开发专业代码听起来像个好主意;我也喜欢将开发人员暴露给QA世界，因此他们知道如何提倡缺陷修复。

以下是关于这种方法的利弊的一些想法。

优点：

1. QA会更好地感受到工作 在真正的发展环境中。 很多时候，质量保证会降级为广告 临时脚本创建，自动化 测试是有点写的 匆匆而且滑倒的方式。这个 可能会给他们机会 将他们的视野扩展到更多 结构化发展周期。这个 也会提供一些见解 他们是如何编写脚本的， 并且可能会提供一些更好的想法 测试开发。
2. QA可能会有更多的赌注 发布周期。虽然从一个 个人观点，我会说我 让我很自豪 我们的发布和质量 其中，有时确实如此 看起来QA没有多少 投资整体产品。 我们经常被视为“虫子发现者” 而不是工程师，我想知道 如果这种方法会给 一个更大的单板 专业性（缺乏专业性） 对QA团队更好的话。
3. 开发人员可能会获得一个 更好地感受QA作为一种练习。我有 经常让开发人员告诉我他们 我不知道我的生活。 开发人员测试代码会 给他们一点点“吃” 你自己的狗粮，“可以这么说。
4. 这将为QA提供机会 稍微扩展他们的简历。很多QA 我所知道的人员都很关心 他们的适销性。好 开发人员通常能够 比较快地找工作; 测试位置似乎更难 找到。任何有帮助的东西 员工拓宽了自己的优势 在该领域的经验将是一个 有吸引力的提案。

缺点：

1. 不应该依赖开发人员 测试自己的代码。在相同的 静脉，QA不应该依赖 测试自己的代码。 “异花授粉”（窃取 兰斯的优秀短语是危险的 因为它可能会导致 人们验证自己的工作。 一般来说，这不是一个 好主意。人们常常失明 为了自己的缺点或 错误，开发代码是最好的 在第三次测试时验证 派对。当然，正确的 监督和管理这一点 过程可以缓解 过程...但这是一个问题。
2. QA不是专业开发人员 和开发人员不专业 QA。无论何时开发人员都会畏缩 递给我他/她已经“测试过”的代码。 并不是我瞧不起他们的 技能组合：相反，我 无法写出他们拥有的代码。 但我也认识到了这些差异 在我们的定义“测试之间 代码。“以同样的方式，我不会， 作为QA人，想要我的代码 给予客户高度的知名度 这可能会伤害或阻碍 客户的关系。注意：我 不一定意味着使命 关键：有时是客户关系 可以通过简单的可用性来削弱 缺陷 - 有点普遍 错误的不成熟的开发人员。 我担心的是高 能见度（我认为包括在内） 任务关键）;我知道我不是 专业开发人员，我 我不想被认为是这样 标准。
3. 这增加了机会 重工。我不一定相信 开发人员充分测试代码， 他们不应该考我 充分发展解决方案。在 两种情况下，都有可能 有人需要回去 以前的工作“正确”会这样做 关心。

总的来说，我认为这个想法非常有趣，听到有关此事的故事会很棒。

我参与的一个类似方法是“bug days”。在这些日子里，开发人员坐在QA旁边，他们合作找到尽可能多的缺陷。像这样的日子非常出色：QA和开发团队之间的专业关系得到加强，对彼此技能的尊重通常会增加：开发人员可以更好地了解QA如何发现错误，QA可以更好地了解开发人员在他们发出嘎嘎声时知道多少解决你发现的bug。这不是解决问题的完美方式：QA仍然没有做太多的生产级代码。但它确实有助于促进各职位之间更好的理解。

Answer 3

我认为开发人员应该专注于编写生产代码和单元测试，而QA应该专注于集成测试，测试自动化和验收级别测试。如果QA团队很好，并且API文档很好，我认为QA可以编写根据规范运行API的单元测试。

我与之合作的很多QA人员都更擅长编写程序代码，例如自动化脚本。我不确定我是否希望他们编写生产代码，特别是当使用复杂的，面向对象的设计模式时，或者超出基本编码级别的任何东西时。

只是我的意见。

Answer 4

每家公司都不同。对一家公司有效的方法不一定会自动适用于另一家公司。

那就是说，当然，拥有尽可能全面的员工是有道理的。有人拥有的知识越多越好。您是否强制某人为新版本贡献代码？我不太确定它是否应该是严格的要求。但我认为，如果你只有少量的人，你会倾向于让每个人都做一些事情，不仅是为了传播知识，减少你在有人离开时失去的知识，也因为你可能有比起人们做更多的工作而且不能玩像“我在X部门工作而且我们不接触那个，对不起”这样的游戏。

这听起来合情合理，当然，但不能有一个硬性规则。如果一个优秀的开发人员是一个糟糕的测试人员，我不会反对他们，反之亦然。

Answer 5

我认为进行这种“交叉授粉”是一个好主意，我相信通过更好地了解各自的角色，它可以帮助开发人员和测试人员更有效地协同工作。

Answer 6

将它们放在彼此的鞋子里将有助于他们更多地了解和合作。在任何不同意的时候，他们都会理解对方的立场。

另外，测试对于Dev来说是一次很棒的学习体验。在编写工作的代码时，一点点质量保证会对他/她有一点点的谨慎。

话虽如此，QA 应不应该编写关键任务生产代码而Dev的 应该不是QA'ng任务关键功能。

Answer 7

我看到它运作良好：

• 在一个进行测试驱动开发的敏捷商店中，一个知道CppUnit的C ++开发人员会与知道如何使用内部GUI自动化工具自动化的测试人员配对。对于每个故事，他们将决定哪种组合/ GUI测试最有效，并且他们将共同努力以获得测试/代码。测试人员不知道C ++，开发人员不知道GUI自动化。它非常成功，第一个采用这种方法的项目在全公司范围内进行了演示。该项目中没有人想回到“旧方式”，测试人员落后于开发人员的一两个冲刺。

• Bug Bashes，Guerilla Testing，无论您想要什么，它都是开发人员测试产品的地方。我曾经去过几家商店，这些商店在发现错误方面取得了成功。如果您想添加一些结构并进行报告，Session Based Exploratory Testing可能会非常有用。

• 具有编程技能的测试人员作为初级程序员在开发团队工作了一段时间。在一个例子中，任务是加强团队对某些遗留代码的C ++单元测试。

Answer 8

根据我的经验，QA应该尽可能地了解您的产品以及您的客户。他们应该精通产品的问题领域，并且应该能够解决客户问题以及2级客户支持人员，以解决不需要更改代码的问题。虽然测试脚本是必要的，但并非所有QA人员都需要能够编写它们，因此并非所有QA人员都需要任何编程能力。事实上，不是程序员就会导致QA找到比编码专家更多的错误。

此外，如果您允许QA人员对系统的某些部分进行编码，那么当该部分存在错误报告时会发生什么。他们接管了修复错误吗？如果他们这样做，谁的QAs修复？如果他们不这样做，他们可以在知道代码时对程序员的更改进行QA。知道代码会以微妙的方式偏向您，这就是您首先拥有QA的原因。对于他们来说，系统是黑盒子，他们的工作是确保输入产生正确的输出。知道它是如何做到的不是他们的工作。并且知道如何制造盲点以降低其效率。

另一方面，统计上显着数量的编码员讨厌“测试”。或者将测试视为低级/入门级别的东西。让他们在质量保证方面工作会影响士气，影响生产力。

简答：不。

Answer 9

作为一名QA人，我做了一些编程并实现了新功能。它使我成为一个更好的测试人员，因为我对系统有了更深入的了解。只有两个主要规则要遵循： 1）您无法对自己的代码进行QA，因此QA团队至少需要2个人。 2）它必须经过标准的开发过程，这意味着主要开发人员进行代码审查。

异花授粉很有用。它可以帮助您学习其他技能，并在必要时让员工更容易洗牌。另外，为了让自我得到控制，QA有时会受到回扣的影响。