质量保证与开发比率

Question

我们有一个非常复杂的Java系统，其中包括一些后端层，包括数据库和专有的Swing前端。有外部方可以附加模拟我们的前端的后端API。我们的组织中有大约5个筒仓共享此系统。总共有大约15个开发者维护这个系统。

我们的QA团队的规模应该是什么规则？

编辑：添加基于响应迄今提出的问题有点背景的：

1. 我们每年大约四个主要版本，和一帮之间较小的差异的。
2. 我们的平台有钱易手，所以对我们的客户来说有很多意义。
3. 我们使用正式的错误修正系统。
4. 我们不使用TDD。
5. 我们使用巡航控制等工具进行持续集成。

Answer 1

作为一名前测试团队主管，我建议尽可能多地进行测试。听起来你组织中的很多人都依赖于你的软件。提前测试并经常测试。

认识到测试是每个人的责任是非常重要的。开发人员需要编写好的单元测试。 UI开发人员应该手动测试UI。我试图鼓励测试驱动开发，关注度量（使用正式的缺陷跟踪系统，跟踪缺陷密度等），设置一个持续集成服务，并设计可测试性代码（使用像Spring这样的框架来进行依赖注射，使用嘲笑和存根服务等 - 我很乐意详细讨论）。修复bug的成本在后面找到的代价会越来越昂贵，所以最好在它正式进行QA之前找到它。

杰夫

Answer 2

它可能依赖于代码库如何参与是（是否有很多集成模块），以及如何参与用户体验（如果有很多视觉元素和输入控制进行测试）。

如果这是一个非常复杂的系统，您可能需要为每5位开发人员考虑2-3位QA工程师。但是，如果这些功能并没有真正改变太多或者涉及较少，我认为每5位开发人员（甚至每10位开发人员）只需要1个QA即可脱身。

Answer 3

不，没有经验法则。每个组织都是不同的，因为每个组织都有完全不同的需求，需求，项目等等。你只能找到适合你的组织的东西。

Answer 4

从5个或6个开发者的1个QA开始。然后根据您认为QA需要做多少工作或无所事事开始调整。

事实上，这只是基于我自己的经验，因为涉及的因素太多。您的代码库是如何发展或稳定的？它有多大？测试需要多全面？涉及哪些测试和分析工具？里程碑发布的频率如何？你有什么样的发展过程？多少手动测试和多少自动测试？

还有很多问题。所以从一个任意数字开始，然后从那里开始。

Answer 5

理性QA到dev比率只能被相对衍生于所讨论的应用的复杂性。

显然，一个超级开发者可能会想出一个复杂的应用程序，其中全部只有3个QAs可以高效地测试，因为工作流的复杂性;反过来，对于3个初级开发者来说，可以有1个QA将一个相对简单的输入输出报告应用程序拼凑在一起。

因此，您需要的QA人员数量将取决于您拥有的要求的数量和复杂程度，而不是您使用的软件开发人员的数量。

Answer 6

9年前，我不知道他的观点是否改变了this article，但Joel会推荐每2个全职开发人员1个全职QA人员。我想说，随着系统的不断发展，定期更新，这个比例是相当不错的。

然后，如果系统不经常更改，很少更新，为什么会有许多开发人员开始？我已经伤害到说服自己，1：2是大多数情况下的完美比例。 :)

Answer 7

2名测试工程师每3名开发人员是一个体面的开始。如果很多测试案例涉及无法自动化的东西（物理地插入/拔出东西，UI渲染的直观验证），则每2名测试工程师添加1个测试人员。

Answer 8

这很大程度上取决于系统的功能以及缺陷的后果是什么？你在编写财务软件吗？还是社交网络？一次失败的可能成本大于另一次，因此质量保证工作量不尽相同。同样，如果它是一个产品（多个安装的用户基础可能更难修补），您需要它比内部更稳定。

您还需要问您是否期望他们进行基本系统测试或卷和负载测试。这听起来像是在考虑UI测试和API测试的结合。假设你正在谈论一个“正常”类型的系统，并且我们正在谈论基本的系统测试，那么我认为所有努力的33％应该是测试工作。理论上这给你一个1比2的比率，但是假设你的开发者在单元测试中可能将它拉长到1到3.当然，我现在正在运行1到4，这还不够（我会尽快纠正它该业务允许我）。

但是你也想考虑你的软件开发过程有多成熟，你的规范是什么样的。除了拥有合适数量的测试人员之外，您还需要给他们正确的信息进行测试 - 如果他们没有这些测试人员，那么他们就无法完成工作，这可能是浪费金钱。

另一种选择 - 这听起来像产品已经开发了一段时间。除了常规测试人员的核心功能之外，您还可以使用短期承包商大量进行初始主要测试。如果您只是将测试资源引入您，并不想让他们开始大量积压工作。