在创建工单时间估算时，应在工单估算中包括测试人员（QA）花费的时间吗？以前，我们一直在估计没有测试人员的时间，但是我们正在谈论总是将其包括在内。对于我们当前的sprint（发布前的最后一个）而言，这很有意义，因为我们需要知道一星期后的总时间。

我一直都知道估算只是为了开发人员时间，因为这往往是团队中的限制资源。一位同事说，无论在测试人员时间之前在哪里工作，也都包括在内。

需要明确的是，这是针对开发人员编写覆盖面广的单元测试，集成测试和UI测试的过程。

我的建议：您可以在故障单中包含测试时间，或者添加故障单以表示测试任务本身。任何其他方法都会使您低估所需的实际工作。

虽然开发人员时间通常是一个瓶颈，但以我的经验来看，有许多团队在测试中受到限制。假设限制资源是一种或另一种而没有证据，可能会咬你。

作为您的同事，我还没有看到一个没有考虑测试时间的成功组织。

根据您的澄清，附录：即使开发人员编写了自动化测试，尤其是单元测试（集成测试更好），它们也不足以正确测试。

如果有质量检查人员参与，则需要以某种方式估算他们的时间。仅当您决定从工资单中删除质量检查人员时，他们的工作时间才有效地消失了，您可以将其从估算中删除。但这会产生容易忽略的副作用。而且您可能仍然缺少性能，压力，安全性和验收测试。

重点是

测试是开发过程的一部分。如果您的团队确实花费时间测试软件，则花费的测试时间必须包含在估算中。

如果这很敏捷，我会将测试工作作为总故事点的一部分。例如，开发人员的精力可能是1天，而测试是1天，那么这将是2分的故事。

这取决于您对完成的定义是什么，但是通常它的开发完成，业务接受度和测试会在迭代中签字。如果国防部只是业务上的接受，那么就不必在测试点中包括测试工作，但仍应对其进行跟踪。

概算应说明完成票证所需的所有工作。如果测试是入场券的必需部分，则应将其包括在估算中。如果测试是单独的票证，那么就不应该。

一旦开始使用故事点，那当然会变得很模糊，因为仅开发人员5和仅开发人员8之间的差异将与开发人员和质量检查人员5与开发人员和质量检查人员8成正比。

我已经看到包括测试人员的时间工作。我看过单独的故事。我见过单独的任务，每个任务都是由工作组估算的。尽一切可能为您服务，然后做对您而言有意义的事情，反之亦然。

您无法回答这个事实强烈说明您不知道为什么要编写估算值（或者至少您与同事不同意为什么要编写估算值）。这比估计是否应该包含测试更大的问题。

找出或达成共识，为什么要编写估算值。如果要预测某个特定团队在特定时间内将取得的成就，那么答案仅取决于该团队（您要评估的那个团队）是否进行测试。如果您的质量检查团队是独立的并且有自己的时间表，那么他们可能会想知道您（开发人员）认为在给定票证上需要从他们那里花费多少测试时间。他们可能会忽略您的数字并投入您自己的数字。无论哪种方式，他们都可以将其与开发时间估算值分开跟踪。

另一方面，如果一个团队正在做所有的开发，测试和质量检查，并且时间估算的目的是预测和计划该团队在特定时间范围内的工作，那么时间估算当然必须包括质量检查以及该团队为实现既定目标而必须执行的其他任何任务。对于这个问题，如果你必须有一个开球会议为每票或填充在完成文书工作的一些位，那么对于管理员的时间必须在那里的某个地方。您不能只是忽略它。

如果是一个团队，但角色分别为“开发人员”和“测试人员”，那么这可能意味着您有很多票证，只有鸿沟的一侧可以处理，并且（也许完全是假设的）甘特图看起来就像两个独立团队的图表一样。这个事实将使某些方法比其他方法更令人不快，因此，您最好拆分计划，但如果不拆分，则必须出票并估计团队需要做的一切，否则您的预测将是无望的。

如果估算的目的不是预测和计划之外的其他事情，例如“因为我们无意识地遵循了包含这些估算的空礼”，或“因为管理人员将其作为坚持不懈的手段来击败我们，以使我们摆脱超时”，或“因为我们必须进行固定价格的出价，而且价格变成一个巨大的公式”（感谢John Wu），所以可能很难弄清楚它们应该包括什么；-)

始终估算要真正完成用户故事/功能/票务所需完成的所有工作。我们称之为DoneDone。

当我们准备生产时，我们就完成了。

这包括任何手动和探索性测试，甚至包括用户接受性测试。

敏捷团队应该能够随时发布完成工作的新部分。如：

工作软件是进度的主要衡量标准。

如果尚未测试，如何知道它是否有效？现在，您写到开发时间是您时间的瓶颈。作为质量检查工程师，我认为大多数团队的测试能力都有瓶颈，或者只是捷径而已。

长话短说，还请估计测试工作量。请记住，这可能会影响您的速度。如果您一直在进行故事点的相对估计，则测试可能已经包含在您的平均速度中。

这是非常重要的事情：所有估计值都应附带假设和排除项。

这包括指定包括的内容：仅开发，设计和开发，开发和单元测试，验收测试的覆盖范围，基础架构的扩展等。

如果要向项目经理提供估算文件，他们将把该文件转换为客户或PMO（如果是内部项目）的工作单或工作说明。他们可能已经设定了增加费用的公式（例如，某些项目可能会增加X％来涵盖质量保证，然后再增加Y％来涵盖治理和项目管理），这些公式是由合同或经验确定的。而且您不想重复计算。另一方面，他们可能不会自动添加它们。

做法不同。无论谁使用这些数字，都需要知道数字的含义，并且应该明确说明是否包括测试时间。

时间应包括在估算中，但您不应估算测试人员的时间，相反，测试人员应估算其时间。

不包括测试时间是对将花费的总时间的错误估计，但是开发人员时间和测试人员时间不可互换（尤其是因为您可能与测试人员并行工作，后面有一个迭代），因此您应该分别估计它们。而且，您无法估计测试人员测试任何更改所需的时间，只有测试人员自己应该这样做。

封装形式

我将从软件开发的角度和语言来解决这个问题。

• 您是大型机器中的小齿轮。
• 从团队外部，票务系统充当团队的接口/ API
• 使用票务系统的企业用户不是开发人员

通过良好的软件设计，您应该尽可能简化和封装。

因此，从业务用户的角度来看流程，他们实际上只关心两件事。

1. 它要花多少钱？
2. 我们完成了吗？

让业务用户知道您团队的内部流程是不好的管理；类似于允许public访问内部状态。

无法保护您团队的内部状态，正在邀请其他团队管理您的资源并弄乱您的内部状态。