开发人员与测试人员的比例是多少?

时间:2009-01-22 15:01:30

标签: testing qa user-acceptance-testing

人们认为[高级]开发人员与测试人员的比例最好?

显然,这在一定程度上取决于开发/维护吞吐量,但新公司/项目是否有可能起作用的经验法则?

另外,您是否会使用“纯”测试人员,还是将测试与其他角色(例如文档,用户培训等)结合使用?

显然,答案可能取决于所使用的公司战略/开发模式,因此请说明您是否正在回答,或者是否针对特定风格的产品/发布等等。

10 个答案:

答案 0 :(得分:12)

Joel makes a good argument为每2名工程师提供1名测试员,并涵盖人们因没有这些测试人员而使用的借口。

答案 1 :(得分:6)

我曾在here发表过关于此事的博文。最相关的摘录如下。

“我见过以10:1的开发:测试比例生产的高质量产品,以及1:1比例创造的可怕产品。不同之处在于关注和关注质量。如果每个人(包括管理层)都在团队非常关心产品质量,无论比例如何,都很有可能发生。但如果质量是应该在产品中测试的,那么每个开发人员至少要有一个测试人员 - 如果你可以得到它们。“

答案 2 :(得分:5)

最近有一篇关于InfoQ的相关文章,您可能会感兴趣。

答案 3 :(得分:5)

首先,开发人员对测试人员来说是一个很好的经验法则,但它是糟糕 规则

您需要考虑的是您的应用程序有多少用例。用户将以不受控制的方式(I.E.Web应用程序或桌面应用程序)与之交互的应用程序将需要比类似控制台应用程序更多的测试人员。

采用单个文件并检测其中的正则表达式模式的应用程序将需要比新操作系统更少的测试人员。

虽然这些是一般格言,但实际建议是根据这些因素使用某种近似公式

1)有多少(分隔的)用例?

我说区分用例,因为如果你包含状态更改和持久变量,那么程序中看似无关的部分可能会变得相关。 I.E. 2 + 2 = 4(1用例)2 * 2 = 4(第2用例)。那是两个简单的运算符,两类用例。但是,如果你可以add然后multiply,那么你不能单独检查addmultiply,你必须检查所有可能的排列。

在检查用例数时,请确保包含涉及命令链接的用例。

2)测试每一个需要多长时间?

这并不意味着(扩展计算器比喻)只添加2 + 2并查看答案。您必须包括从崩溃中恢复所需的时间。如果答案不正确,您可能希望测试人员使用屏幕截图和有关如何重新创建错误的具体说明来记录错误。如果你没有给他们时间进行这种管理工作,那么你就可以假设你没有错误。如果我们假设,那么为什么要有测试人员;)

复杂项目将包含大量用例和大量开发人员,但它们不是保证相关性。您最好彻底检查您的用例,并做出有关需要多少测试人员的明智决定。

添加奖金。一旦你彻底破坏了应用程序,你可能会发现一些在设计阶段从未考虑过的用例,并在测试人员找到它们之前修复它们。

答案 4 :(得分:4)

这个字符串显然很旧。但在我看来,答案都错过了这一点。

1)。开发人员和测试人员的比例问题是有效的,因为需求越复杂,需要的开发人员就越多,因此需要的测试人员就越多。相当多的回复似乎都忽略了这一点。

2)。无论应用领域如何,在现实世界中为“高质量”软件制定的良好比例是2:1。你可能会以4:1的比分生活,但它真的很舒服。当然,此估算中有许多变量,不仅要求的复杂性,要​​部署的系统/环境,还有开发人员的工作效率,以及交付时间表的紧密程度。

HTH

答案 5 :(得分:3)

在我看来,用于确定所需测试人员数量的一个好指标是需求的复杂性,而不是开发人员的数量。如果我正在招聘测试人员,我会查看需求列表(或者在必要时将设计文档分解为需求列表),并考虑每个需求需要多少测试时间来验证它是否正常工作。我会使用初始分析来雇用一组测试人员,然后如果工作负载对我的初始基础来说太高而添加测试人员。

如果您正在制定预算并且以后招聘测试人员不是一种选择,那么您可能希望预算的测试资源略多于分析所显示的。太多总是比不够好。

是否使用“纯”测试仪是另一个问题,它实际上取决于您需要多少测试资源。我发现一个很好的折衷方案是聘请能够从事其他工作的测试人员,并在测试负载很轻的时候以其他身份使用它们。

编辑:如果您有幸在早期进行一系列验收测试,请将“验收测试”替换为上面的“要求列表”。 : - )

答案 6 :(得分:2)

没有普遍的“好”比率。

显然,测试某些内容所需的时间是上下文的 - 它取决于与开发该功能所花费的时间很少或无关的因素。

还要考虑:

  • 什么算作发展?
  • 什么算作测试?
  • 如果我们无论如何要进行回归测试,那还算是“零”额外的测试时间吗?

请参阅:http://www.sqablogs.com/jstrazzere/150/What+is+the+%22Correct%22+Ratio+of+Development+Time+to+Test+Time%3F.html

答案 7 :(得分:1)

我会说(取决于您需要测试的速度)自动化,您可以为每5位开发人员提供1或2个测试人员。

为什么:

  • 通过自动化,他们只需要担心测试新模块
  • 回归测试将照顾旧的。
  • 1或2名测试人员可以轻松涵盖5位开发人员将要做的所有工作,例如每周/每周
  • 我教过的一个很好的比例是,每开发10个小时,质量保证团队将花费3到4个小时来跟踪那些10小时产生的大部分缺陷。

希望它会有所帮助:)

答案 8 :(得分:1)

  

另外,你会使用'纯'测试者,或者   你会把测试与其他测试结合起来   角色(例如文档,用户   培训等)?

这取决于测试的类型,但我不会给具有其他角色的测试人员带来负担。有能力的测试工程师非常重视黄金(与有能力的软件工程师一样)。如果你给他们的专业领域之外的任务,你将减慢他们的速度,并将他们关闭。软件工程师喜欢做文档还是用户培训?通常不是。测试人员也没有。

但是,向其他领域的人员补充测试团队没有任何问题,尤其是可用性测试,验收测试,快速评审等。

答案 9 :(得分:1)

有一件事是肯定的。测试人员的数量应该大于开发人员的数量。对于开发人员创建的每个功能,测试人员必须在各种类型的测试中运用该功能:功能,可用性,边界,压力等。虽然确切的比例将更多地取决于测试用例的数量以及测试周期应该多长时间(1周,3天,1天或半天),单个开发人员将为多个测试人员生成足够的测试活动。此外,可能存在需要多个测试人员模拟在系统上同时工作的两个或更多用户的情况。