我不禁注意到，随着质量检查团队的每一次新增加，我们的会议变得越来越长，从某种意义上说，效率也降低了，因为某些主题对其他人而言变得不那么重要了。 ;我们正在处理比以往更多的产品和流程，要使测试人员“具有通用性”，要对整个生态系统和被测产品有广泛的了解就变得充满挑战。
这可能是“从某种意义上说“拥有”，但是对于单个QA团队的规模有普遍建议吗？哪些因素和指标可以帮助您解决问题？
#1 楼
您将获得有关质量检查团队规模的各种建议，从零到开发人员数量的两倍，甚至更高。合适的数量取决于您需要测试的内容，开发人员进行的测试类型以及软件的坚固程度。我的经验是，小型团队-不超过少数人-比大人物更有效。如您所见，更大的团队需要更多的时间进行沟通和协调。
您可能已经到达了一个不切实际的地步，指望每个测试人员都是通用的，并且具有对整个生态系统和被测产品的广泛了解。也许没关系。考虑将您的大团队分成一些专门的小团队。尝试在每个团队中至少任命一名通才。
评论
开发人员的两倍？他们背后有理论吗？
–张瑜
17年12月15日在19:12
@YuZhang Devs在一天中产生的错误是人类发现的错误的两倍？听起来不错，根据我自己的代码。
–莫妮卡基金的诉讼
17 Dec 15 '23：00
@YuZhang也许值得花可靠性的时候？核电站，太空发射器，用于Carol in Accounting的电子表格等。
–corsiKa♦
17/12/16在2:17
@YuZhang-我曾在dev：tester资源比率在1：1.5至1：1.7之间波动的组织中工作-我们感到有时候测试人员不足。如果碰到一个组织，我真的不会感到惊讶。 1：2。
– shalomb
17年12月16日在2:21
@QPaysTaxes，谢谢，向我建议的最高QA / Dev比率是1：1，但我从未想到过会超过1：1。
–张瑜
17年12月16日在3:47
#2 楼
您可能需要考虑将质量检查团队分成较小的小组，以便他们可以专注于特定产品。保持QA工程师“通用”的能力对敏捷团队而言并没有真正的作用，特别是在允许与其合作的应用程序工程师专门化的情况下。#3 楼
TL; DR：越小越好，我的目标是3-6人。随着团队规模的扩大，沟通的开销显然会增加。我估计转折点大约是10到12人，现在彼此之间会互相影响，并且会给您带来一些真正的交流困扰。实际工作，只有少数利益相关者（3-5）投入团队积压的工作。然后，团队可以决定要投入什么。如果工作量超出单个团队的处理能力，我将在同一积压订单中投票选出第二个团队。现在，团队必须找出一些协调机制，而这通常并不包括整个团队。最简单的形式可以是每日Scrum of Scrums。不管是质量检查团队，开发团队还是销售团队，都不要紧。他们可以以相同的方式运作和组织。
更大的团队也有更高的周转率，人们来去（团队或公司）。使团队发展阶段重新组建。这是非常无效的。较小的团队可以使团队保持在一起更好，更容易。
团队越小，自组织性越好，但最少也要有3-4个人。尝试将总线系数限制在3左右，这意味着团队成员不应充当个人。
评论
+1，类似于《神话人月》中定义的“外科团队”。这本书的保存情况令人惊讶：35年后，仍然有效。经过这么多时间之后，没有其他IT书如此重要。
–Peter M.-代表莫妮卡（Monica）
17年12月19日在15:39
#4 楼
我认为质量检查团队没有“理想”的规模-它可能取决于项目，公司和许多其他因素。通常，质量检查团队的规模不应该太大足以成为瓶颈，但是如果测试成为瓶颈，那么您将增加质量检查团队的规模。测试是非常依赖技能的。您的开发人员可能有大量的输出，可能要进行2甚至3个QA的测试（是的，我已经看过，并且曾经是其中的QA。反之亦然，其中3-5个开发人员很容易进行工作由一个单独的质量检查人员管理。
也增加了人员或固定比例的开发人员：质量检查人员是一个坏主意-如此处http://kaner.com/pdfs/pnsqc_ratio_of_testers.pdf
项目的复杂程度还可能决定您或您的团队可能需要多少QA，以便交付高质量的项目并覆盖复杂性。是决定团队质量保证的关键因素，客户交付项目可能比内部请假管理系统项目需要或具有更多质量保证。
#5 楼
在我过去的工作中，质量检查小组的规模约为30至50人。但是，质量保证已分发给开发团队。因此，我们平均每3-4个开发人员大约有2个质量检查人员。平均而言，每2个开发人员有1个质量检查人员。质量检查人员大多是手动的（〜99％）。他们确实被证明是一个足够的瓶颈（尽管他们讨厌被称为“瓶颈”）。我们有一个单独的“自动化团队”，根据产品最关键的功能为“整个公司”提供自动化测试。
因此，要回答您的问题：我首先要确定如何质量检查有很多瓶颈（如果有的话）？这样应该可以更有效地告知您质量检查的大小（无论是手动还是自动）。 。但是，就“完成这项工作的时间/精力”而言，理论上的质量检查工作几乎为1：1。 1：1 dev：QA比率可能会使我们做得更好，但是预算不允许这样做。通讯开销也太多了。但是，我们从未检验过该假设。我不确定是否对此进行任何研究，但是从经验上讲，这是我们发现的结果。质量检查小组。使用该信息并与功能交付效率进行比较，您可以对质量检查团队的潜在规模有一个很好的判断。如果您没有预算，则可能需要尝试-例如，让一些开发人员担任QA或让QA经理加入以增加资源池，雇用承包商等，或者只是发挥创意！ br />
#6 楼
我管理一个质量检查小组，并向每位面试候选人提出这个问题。我得到的答案大多是质量保证人员与开发人员的比例在1：2和2：1之间。测试主题是，开发人员将进行哪种测试，以及软件需要具备多强的稳定性。找到一些好的指标，以帮助您找出合适的平衡点。我观察了为开发人员创建的新问题的数量，以及每周测试多少个问题。如果我发现开发人员创建的工作量超出测试人员无法承受的趋势，我便开始要求更多的测试人员，并且我有一些可靠的数据来备份我的请求。
#7 楼
我见过的最高效，最有生产力的团队就是功能团队，只有3位成员-1位业务分析师，1位开发人员和1位测试人员，其中3位通才多于专家。乍一看，它看起来似乎不是有效的合成，但从长远来看，它们是真正有效和非常有效的，因为他们真正的团队合作是通过非常开放和透明的沟通来完成短距离冲刺的功能，其中反馈回路非常短，有时是看不见的。
#8 楼
对于N人的团队，要在每个成员之间进行通信，您需要N *（N-1）/ 2个链接。它是二次函数O（N ** 2），因此显然不能很好地缩放。为了避免低总线系数（试图使数字朝相反的方向倾斜），最佳大小为2.5：一名主题专家，一对配对/学习以成为一名，并且具有总体思路，并在必要时可以介入。并且有多个团队，每个专业领域一个团队。当然这需要专业化，有些人认为专业化是针对昆虫的，您需要有能力的通才QA-但您可以负担得起，并为此付费交叉训练所需的时间？
#9 楼
是时候专门化和创建较小的专家团队了。可能的方案：领域知识团队
工具知识团队
测试类型知识（黑盒团队和白盒团队）
基于平台的团队
我可能首先将人员分为测试（测试软件的人员）和QA（防止缺陷出现在软件中的人员）团队。
评论
您可能听说过《神话人月》。尽管它不直接与质量检查有关，但确实与软件开发环境中的团队规模有关。这场辩论对我而言似乎一直是一个红场。更重要的是确保开发人员至少进行一些基本的验证，文档编制和回归测试/单元测试/记分板（可选地嵌入团队中的SET /测试人员）。并且应该有一些SCM流程，不需要是CI，但是需要防止废话进入分支机构，并尽早进行检测。但是，从房屋的开发侧对大型的整体质量保证部门进行防火墙防护，并不断向其投入几乎没有工作的代码，然后争论该部门的最佳大小，这完全是赤字。
更为相关的问题是：测试职责是否在传播，而不仅是失败的质量保证？ dev，DevOps和QA之间的工作关系如何运作？当废话被检入dev分支时，是通过测试失败/代码审查/回归失败检测到的，还是要等上几个月才能被质量检查人员发现，然后又因为功能变更/增强而捆绑了呢？基本上，由于公司范围内缺乏结构化的开发和测试流程，因此质量检查不是实现愿望的对象。尽管经常这样对待。
因此，这个问题完全是错误的问题。还有“ [质量检查]的哪些因素和指标？”这是另一个要问的错误问题，它使我们得到了诸如活动错误计数，关闭时间之类的bodycount风格的部门级废话指标，这些信息无法提供更多信息。甚至没有修补测试覆盖率漏洞的速度。更不用说组织范围内的指标，例如“我们是否可以在n个月内定义，规范和发布基本满足客户需求的代码？” （敏捷vs瀑布是另一个错误的辩论。只需使代码正常工作。无论哪种过程都适用于该客户群）。
@codeaviator-我想知道，如果人们只读这本书，会回答多少个问题。 35年后，它仍然像其他IT书一样拥有。