我们有一个相当复杂的 Java 系统，其中包括一些后端层，包括一个数据库和一个专有的 Swing 前端。有一些后端 API，外部各方可以附加这些 API，以模仿我们的前端。我们组织内大约有 5 个孤岛共享这个系统。总共有大约 15 名开发人员维护这个系统。
我们的 QA 团队的规模是否有经验法则？
编辑：根据迄今为止的回复中提出的问题添加一些上下文：
作为前测试团队负责人，我建议尽可能多地进行测试。听起来您组织中的很多人都依赖您的软件。尽早测试并经常测试。
认识到测试是每个人的责任是非常重要的。开发人员需要编写好的单元测试。UI 开发人员应该手动测试 UI。
我尝试鼓励测试驱动开发，关注指标（使用正式的错误跟踪系统，跟踪缺陷密度等），设置持续集成服务，并设计可测试性代码（使用像 Spring 这样的框架进行依赖注入，使用模拟和外部服务的存根等 - 我很乐意更详细地讨论）。修复错误的成本会随着您越晚发现而成倍增加，因此最好在它进入正式 QA 之前找到它。
杰夫
从对 5 或 6 名开发人员进行 1 次 QA 开始。然后根据您认为 QA 必须做或无事可做的工作量开始调整它。
事实上，这只是基于我自己的经验，因为涉及的因素太多了。您的代码库的开发程度或稳定性如何？它有多大？测试需要多全面？涉及哪些类型的测试和分析工具？里程碑版本多久发布一次？你有什么样的开发过程？多少手动测试和多少自动化测试？
还有很多问题。因此，只需从任意数字开始，然后从那里开始。
合理的 QA 与开发人员的比率只能根据相关应用程序的复杂性得出。
显然，由于工作流程的复杂性，超级开发人员可能会提出一个复杂的应用程序，其中只有 3 个全职 QA 可以有效地进行测试；反过来，可以为 3 名初级开发人员进行 1 次 QA，拼凑一个相对简单的输入输出报告应用程序。
因此，您需要的 QA 人员数量将取决于您拥有的需求的数量和复杂性，而不是您使用的软件开发人员的数量。
很大程度上取决于系统的功能以及缺陷的后果是什么？你在写财务软件吗？还是社交网络？一个失败的可能成本大于另一个，因此 QA 工作会有所不同。同样，如果它是一个产品（安装了多个可能更难修补的用户群），您需要它比内部产品更稳定。
您还需要询问您是否希望他们也进行基本的系统测试或容量和负载测试。听起来您正在查看 UI 测试和 API 测试的组合。
给你一个起点，假设你说的是“正常”类型的系统，而我们说的是基本的系统测试，我要采用的指标是所有工作的 33% 应该是测试工作。从理论上讲，这给您一个 1 比 2 的比率，但假设您的开发人员正在进行单元测试，可能会将其扩展到 1 比 3。当然，我目前正在运行 1 比 4，这还不够（我会尽快纠正它）业务允许我这样做）。
但是您还需要考虑您的软件开发过程有多成熟以及您的规范是什么样的。除了拥有正确数量的测试人员外，您还需要为他们提供正确的测试信息——如果他们没有这些信息，那么他们将无法完成工作，这可以说是浪费金钱。
另一种选择 - 听起来该产品已经开发了一段时间。除了常规测试人员的核心外，您可能还想使用短期承包商进行初始主要测试。如果您只是引入测试资源，您不希望以大量积压开始它们。
这可能取决于代码库的参与程度（是否有很多集成模块）以及用户体验的参与程度（如果有很多视觉元素和输入控件要测试）。
如果这是一个非常复杂的系统，您可能需要为每 5 个开发人员考虑 2-3 个 QA 工程师。但是，如果这些功能并没有真正改变太多或涉及较少，我认为您可以为每 5 名开发人员（甚至可能每 10 名开发人员）只需 1 次 QA。
不，没有经验法则。每个组织都是不同的，因为每个组织都有一组完全不同的要求、需求、项目等。您只能找到适合您组织的内容。
我不知道自 9 年前这篇文章以来他的观点是否发生了变化，但 Joel 建议每 2 名全职开发人员配备 1 名全职 QA 人员。我想说，对于一个不断发展、定期更新的系统，这个比例相当不错。
再说一次，如果您的系统不经常更改，很少更新，为什么要开始有很多开发人员？我已经成功地说服自己 1:2 在大多数情况下都是完美的比例。:)
每 3 名开发人员 2 名测试工程师是一个不错的开始。如果许多测试用例涉及无法自动化的东西（物理插入/拔出东西，UI 渲染的视觉验证），则每 2 名测试工程师添加 1 名测试员。