2

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

我不是在谈论单元测试。我说的是一个专注于系统的 QA，也贡献了一些生产代码，以及一个开发人员花一些时间分析和测试系统的一个单独部分。

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

4

9 回答 9

11

需要考虑的几点：

  • 大概，你雇佣你的开发人员是因为他们擅长编写代码，而你的测试人员是因为他们擅长 QA。从商业角度来看，付钱让他们做彼此的工作是否有意义？
  • 如果你的测试人员太了解代码，他们会产生盲点吗？
  • 同样，您的开发人员真的可以成为有效的测试人员吗？他们对应用程序有深入的了解吗？
于 2009-05-07T03:06:52.140 回答
8

作为一名 QA 人员，我觉得这个想法很有趣。有机会开发专业代码听起来是个好主意。我也喜欢让开发人员接触 QA 世界的想法，这样他们就知道如何倡导缺陷修复。

以下是关于这种方法的优点/缺点的一些想法。

优点：

  1. QA 会更好地感受在真正的开发环境中工作。很多时候，QA 被降级为临时脚本创建，其中自动化测试以某种匆忙和草率的方式编写。这可能使他们有机会将视野扩展到更有条理的开发周期。这也将提供一些关于他们如何编写脚本的见解，并可能为更好的测试开发提供一些想法。
  2. QA 可能在发布周期中有更多的利害关系。虽然从个人的角度来看，我会说我将很多自豪感与我们的发布和其中的质量联系在一起，但有时看起来 QA 确实对整个产品没有太多投资。我们经常被视为“错误发现者”而不是工程师，我想知道这种方法是否会给 QA 团队带来更大的专业精神（因为没有更好的词）。
  3. 开发人员可能会对作为一种实践的 QA 有更好的感觉。我经常让开发人员告诉我，他们不知道我靠什么谋生。可以这么说，让开发人员测试代码会让他们有点“吃自己的狗粮”的味道。
  4. 这将使 QA 有机会扩展他们的简历。我认识的许多 QA 人员都担心他们的适销性。优秀的开发人员通常能够相对较快地找到工作；测试职位似乎更难找到。任何可以帮助员工拓宽他们在该领域的经验的东西都是一个有吸引力的提议。

缺点：

  1. 不应依赖开发人员来测试他们自己的代码。同样，不应依赖 QA 来测试他们自己的代码。“异花授粉”（借用兰斯的名言）是危险的，因为它可能导致人们验证自己的工作。一般来说，这不是一个好主意。人们常常对自己的缺点或错误视而不见，而开发的代码最好在第三方测试时进行验证。当然，对这个过程进行适当的监控和管理可以减轻这个过程……但这是一个问题。
  2. QA 不是专业的开发人员，开发人员也不是专业的 QA。每当开发人员将他/她“测试”过的代码交给我时，我都会感到畏缩。我并不是看不起他们的技能：相反，我无法编写他们拥有的代码。但我也认识到我们对“测试代码”的定义之间的差异。同样，作为 QA 人员，我不希望我的代码对客户具有高度可见性，这可能会伤害或阻碍客户的关系。注意：我并不一定是指关键任务：有时客户关系可能会因简单的可用性缺陷而受损——对于不成熟的开发人员来说这是一个有点常见的错误。我担心的是高能见度（我认为包括关键任务）；我知道我不是专业的开发人员，我不想被要求遵守同样的标准。
  3. 这增加了返工的机会。我不一定相信开发人员能够充分测试代码，他们也不应该测试我来充分开发解决方案。在这两种情况下，有人需要回顾以前的工作以“正确”地做这件事的可能性将是一个问题。

总的来说，我认为这个想法非常有趣，很高兴听到有人尝试过这个想法。

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

于 2009-05-07T03:41:19.297 回答
2

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

与我共事过的许多 QA 人员更擅长编写过程代码，例如自动化脚本。我不确定我是否希望他们编写生产代码，尤其是在使用复杂的、面向对象的设计模式或超出基本编码水平的任何东西时。

只是我的观点。

于 2009-05-07T03:00:11.643 回答
1

每个公司都不一样。适用于一家公司的东西不一定会自动适用于另一家公司。

也就是说，当然，拥有尽可能全面的员工是有意义的。一个人的知识越多越好。如果你强迫某人为新版本贡献代码？我不太确定这是否应该是一个严格的要求。但我认为，如果你只有少数人，你会倾向于让每个人都做一点点，不仅是为了传播知识并减少你在某人离开时丢失的知识，而且因为你可能有工作量比人多，而且玩不起像“好吧，我在 Dept X 工作，我们不碰那个，对不起”这样的游戏。

当然，这听起来合理且务实，但不可能有一个硬性规定。如果一个好的开发人员是一个糟糕的测试人员，我不会反对他们，反之亦然。

于 2009-05-07T02:52:09.057 回答
1

我认为拥有这种类型的“异花授粉”是个好主意，我相信它可以帮助开发人员和测试人员更好地了解他们各自的角色，从而更有效地合作。

于 2009-05-07T03:00:12.033 回答
1

设身处地为他们着想将有助于他们更多地相互理解和合作。在任何不同意的时候，他们都会理解对方的立场。

此外，测试对于开发人员来说是一种很好的学习体验。一点点 QA 会让他/她在编写有效的代码时更加谨慎。

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

于 2009-05-07T03:00:58.287 回答
1

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

异花授粉很有用。它可以帮助您学习其他技能，并在必要时更轻松地调动员工。另外，对 QA 来说，稍微受到回扣的影响是有好处的，以控制自我。

于 2009-06-02T19:16:06.960 回答
1

我已经看到它运作良好：

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

  • Bug Bashes，Guerilla Testing，随便你怎么称呼它，开发人员测试产品的地方。我去过几家商店，就发现的错误而言，这是成功的。 如果您想添加一些结构和报告，基于会话的探索性测试在这里会很有帮助。

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

于 2009-05-07T04:26:24.430 回答
1

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

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

另一方面，统计上显着数量的编码人员讨厌“测试”。或将测试视为卑微/入门级的东西。让他们从事 QA 工作会影响士气，进而影响生产力。

简短的回答：没有。

于 2009-05-07T04:31:16.370 回答