多个产品特定的质量检查小组与一个通用的质量检查小组

#1 楼

是的。

我建议将两者结合起来：一个负责所有产品的质量检查团队，由专家和通才混合而成。

在这个团队中，您理想的情况是希望混合使用各种技能：一些熟练于产品A的人员，某些熟练于产品B的人员，以及一些可以浮动/专门从事测试领域/技术（例如性能，安全性，可用性等）的人员。这样，您可以确保人们总是有事要做。如果您有专门从事性能测试产品A的人员，那么在产品A尚未准备好进行性能测试时，他们会怎么做？ （我在这里假设管理层不允许某人花费一半的时间来提高自己的技能，开发工具或类似方法。）

这种方法的优点如下：


当产品需要一段时间进行重点测试时，您可以将人们转移到该产品上，而无需使用“闲置”测试人员。
它可以简化工具，技术等的共享。
从职业角度来看，比较质量检查人员与质量检查人员与开发人员之间的比较容易。

缺点：


您必须为这些不同的角色找到合适的人选。有些人会想专精，另一些人会想浮动。如果您尝试让一种人不适合他们，这可能是一个问题。
根据所涉及的产品，如果共享技能/工具/等可能会成为问题，如果它们之间的差异足够大，以至于需要非常不同的测试技能，工具或其他任何东西。
团队越大，机构惯性就越大。在一个小的团队中，他们会更容易使用新工具/技术/等，因为说服的人会更少。

不过，老实说，较大的团队模型的一个优点是，在某种程度上，除非您的管理团队受到严格的纪律约束，否则项目之间几乎总会有一些共享，因为当前的问题项目将要求/要求更多资源。有了一个更大的统一团队，您可以更轻松地吸收这些资源。

从管理的角度来看，让质量检查经理与开发经理具有同等地位是非常有帮助的。这是因为开发要交付时总是会发生冲突，而QA认为产品尚未准备就绪。理想情况下，您希望基于技术理由做出此决定，而不是因为开发经理在某种程度上比QA经理高。理想情况下，开发管理和质量保证管理将向同一位经理/执行人员报告，该经理/执行人员负责产品的整体质量，并且他们可以从业务角度进行权衡决策。

（这忽略了将质量检查人员嵌入开发部门的另一种可能性，这有其自身的权衡因素。）

#2 楼

QA都不应该是敏捷交付团队的一部分。我的意思是说，质量保证/测试人员应该与开发人员坐在一起，并帮助他们在迭代过程中交付经过测试的功能。

阅读一些敏捷测试书：http://agiletester.ca/，因为听起来像开发人员正在练习敏捷，但测试却落在了更传统的方法上，例如集群团队。您需要了解产品领域的特定风险等。

#3 楼

到目前为止，我所经历的是质量保证最终有点像咨询公司。我们隶属于产品团队，并与他们紧密合作，开发特定的产品知识和自动化测试。我们见面时，是要比较有关团队，技能和工具的注释。

以我的经验，尝试将QA工程视为一个可互换的工程师部门，每个人在所有方面都经过交叉培训，只会使每个人筋疲力尽，并导致测试不足。而且，由于一名工程师不在，所以另一位工程师可能会在他或她的位置进行同样有效的测试，这有点谬误。拥有“后援”质量保证工程师只是意味着，除了通常使用的任何一种或多种产品之外，还必须对另一个人进行培训并完全了解该产品的最新知识。从长远来看，只说“我们只有一名质量保证工程师对此产品进行计划，可能会比较便宜。”

#4 楼

我认为您可以（应该？）发展您现在已经建立的东西：与开发团队保持“灵活敏捷的关系”的测试人员。是成熟您显然敏捷的环境的好时机。

我认为，只有一个庞大且不断发展的开发（例如编码人员）团队也无法维护不同的产品。因此，这可能是成长为包括编码人员和测试人员的产品团队的最佳时机。与编码人员和需求一样，由于存在特定的专业知识，因此一些测试人员也可以在团队之间共享。正如其他人可能停留在一种产品上。

这取决于您的组织和环境，但是在矿山中，编码人员和测试人员（以及devop和其他技术人员）正在向一位工程经理报告。这也消除了“ QA”作为反对者的问题。还是将“发展”与“质量保证”分开...

如果您要详细比较人员，则可能会更具挑战性，因为在这种情况下，“团队”更多是实体我想来衡量。而且它往往要求（更多）更多的责任感和团队成员的推动力。有些人不喜欢这样。

以我的经验，它确实显示出某些成员确实确实缺乏，行为不当或其他情况，而团队无法处理。在这种情况下，经理需要介入。

绝不是解决方案……它实际上取决于您的上下文；-)

#5 楼

可视化您当前工作场所的结构和动态中两种情况下质量检查资源的典型工作日（因为根据我的经验，每个组织都是独一无二的）。

如果有一个通用的质量检查团队，质量检查人员将在典型的一天与多个产品/功能团队一起工作/互动。

#6 楼

由于存在多种产品，因此必须有特定的开发人员团队来开发特定的产品。如果仍然只有一个通用团队，那么有效地管理测试将非常困难。

宁愿将相应的开发人员和测试人员合并到与产品相关的特定团队中，又要维持一个单独的通用质量检查团队将是一个更好的选择。一般的质量检查小组将负责共同的模块，也可以参与需求分析和管理决策。

否则，质量检查团队将变得扭曲，无头，并且可能会出现这样的情况，即测试人员社区缺乏在开发人员或管理员面前的发言权！

#7 楼

许多公司正在通过跨职能的方法来解决这个问题。

自动化工程师（“测试人员”）与开发人员同地工作，并在各自的Scrum团队中工作。请注意，我使用术语“应用程序工程师”和“自动化工程师”来尝试解决自动化工程师经常遇到的二等公民问题。如果有多个自动化工程师，那么他们可能被认为是应用程序内的本地质量小组开发团队

该组织还将拥有一个“ QA”部门，自动化工程师也属于该部门。该组织的存在是为了雇用，解雇，培训，教育，分享测试知识和方法

组织也可能有一个单独的“人事”经理来处理审查，绩效审查，职业成长和人际关系问题

#8 楼

我的意见是处理多个产品的单一质量检查团队
优点：


产品知识分散到所有质量检查团队
领域知识对所有质量检查团队都增加了
如果缺少一名测试人员，则另一名测试人员将立即选择工作。
工作将更快，更高效地处理任何CR始终存在的错误修复。可以向开发团队公开他们的产品知识

#9 楼

如果您赞成一个质量保证团队，那么您也赞成向咨询公司购买商品吗？

敏捷环境中的质量保证资源应该是跨职能部门的一部分开发团队。他们还应该在整个组织中拥有质量保证实践社区，以便他们可以共享工具和方法来完善其质量保证实践领域。质量检查实践社区需要定义并产生一个文档，该文档指定组织的报告要求。然后由项目团队的质量检查资源来实施报告标准。