测试人员是否应该只为自己估算工作量？

Question

当评估用户故事的努力时，测试人员应该只评估测试工作还是整个团队工作？

如果这个故事在技术上很有挑战性，但比较容易检验，我应该投高票还是低票？

反之亦然，也许它很容易实现，但测试却很复杂。在这种情况下，假设开发者和分析师投3票，我投8票，谁会被听取？

Answer 1

我认为这项估计应由最终会做这项工作的人作出。这意味着每一个角色的赋予和评估，你把它们放在一起。

它总是有点内敛，但在我看来，它似乎仍然比其他人谁不做我的工作估计，我会花多少钱在某事上。在这种情况下，出现错误的空间似乎更大。

我个人的经验是有两种情况：

• 每个角色都给出了他们自己的评估，所以作为一个测试者，我只对我的工作、测试工作进行了评估。
• 测试人员甚至没有被要求提供评估，所以每个人都希望(最好的)测试人员不会在不必要的时间内延迟任何人。

场景2真的起作用只是因为我在说和承诺什么时候完成了事情的时候，我太爱交际了。因此，我设法向团队传达更多真实的评估，即使没有人真的问我。这种方法在很多情况下也会崩溃，但在公司里改变它并不完全取决于我，尽管我不时地指出这一点。

因此，要回答您的问题:基于我认为更好的方法，测试人员只评估他们的工作(测试工作)，而其他人/角色则评估他们的工作。

Answer 2

我认为这种努力取决于“已完成”的定义。

1. 如果在完成的定义中包含了QA，意味着只有在QA完成时，用户故事才会被标记为完成，那么工作应该包括开发和测试工作。
2. 如果and的定义是“合格的QA测试”，那么只考虑开发和集成/单元测试。
3. 如果，您正在处理一个独立的测试用户故事，独立于开发过程(如在TDD中)。然后考虑到唯一的测试工作。

Answer 3

我们使用Fibonacci点来估算相对复杂性，作为测试器，我比较了下面的复杂性，以便与最近交付的特性相比，给出我的整体直觉努力。

我从上到下考虑以下几点：

• 测试复杂性:测试自动化有多难，我们是否有技术测试债务，有时间配置被测试的系统。
• 功能复杂性:工作流有多少步骤、多少排列、有多简单？
• 技术复杂性:我们改变了多少个系统，有多少系统与这个变化交互。
• 开发复杂性:我们的高级解决方案有多复杂？

我们作为一个团队在同一时间就复杂性进行投票。如果测试人员不同意开发人员的意见，有时是因为他们没有考虑到测试的复杂性。然后我解释我的想法，然后我们重新投票。我们几乎总是在第二次投票中获得最高的票数。

因此，我喜欢整个团队，包括测试人员在评估中考虑到整个交付，但将重点放在其他角色可能忘记的部分上。

仅仅考虑到复杂性，而不考虑几个小时，确实存在缺陷。看简短的谈话：7分26秒和敏捷软件开发的基本定理。它是关于基本并发症和意外并发症。我认为这也是评估软件开发如此困难的原因。