敏捷/Scrum团队如何评估测试工作？

Question

在敏捷测试中，哪些是QA过程上下文中最常见的评估技术。故事要点是什么？

Answer 1

敏捷团队是跨功能的团队。他们估计从设计到交付的工作通常是基于故事的水平。这包括测试工作，因为测试应该是已完成的定义的一部分。

故事点是手头任务复杂性的相对大小。阅读更多关于在这个博客中用相对大小进行估计的信息。

作为敏捷团队的测试人员，我总是坐在计划扑克会话中，只与团队一起进行评估，同时铭记完成所要完成的故事所需的测试工作的复杂性和规模。如果我知道我们正在研究的领域缺乏很多自动化的测试覆盖率，我会给出一个比我们团队中的程序员更高的估计值，在这些情况下，我们通常平均出点。

Answer 2

首先，与传统方法( QA估计可能与开发人员估计分开)不同，当以敏捷的方式工作时，您将希望您的软件测试估计数与您的开发人员估计相结合，为每个用户故事生成一个估计。

做这个估计的最常见的方法是使用故事点，其中你的估计是复杂，技术风险，努力等的组合。而不是时间。

规划扑克是最常见的技术，但有许多其他。

加时赛之后，您将了解您的团队的速度，这将使您可以预测多少故事点，您可以完成每次冲刺。当你的团队开始习惯于一起工作时，在同一个项目中，你也应该期待你的速度会提高。

Answer 3

1. 找出基本故事。
   • 非常重要的是，要确定一个或多个基础或参考故事，您将对其进行相对大小的准备工作。这个故事是从当前的产品积压或者我们之前做过的另一个故事中挑选出来的。但重要的是，团队中的每个人对此的理解都是一样的。团队应该对这个基本的故事充满信心。

2. 谈谈故事的要求。
   • 产品所有者或代理PO，将回答问题，并提供解释，确切地说，这个故事需要什么。

3. 讨论并记下你在执行这个故事时想要记住的事情。
   • 这些可以是工具的“注释”部分的故事卡或文本上的要点。这最好由Scrum来完成，他可以在讨论进行时添加这些细节。

4. 这些问题中有一些是团队在开始调整尺寸时问自己的。

1. 设计:在我们开始研究这个故事之前，我们要学些什么？
2. 编码:需要为这个故事编写多少代码？我们以前写过类似的代码吗？
3. 单元测试:单元测试需要任何特殊的设置(例如模拟对象)吗？
4. 验收测试:在帮助客户自动化这个故事的验收测试过程中需要做多少工作？
5. 集成点:这个故事有外部依赖吗？
6. 专家意见:我们中有谁以前做过类似的报道吗？
7. 找到一些相关的比较点。
   • 如果这个故事的工作量和你已经写过的一样多，那么给它同样的分数。如果难度更大，则按比例给它更高的价值。如果这个故事与另一个相似，但在某种程度上工作较少，给它一个较低的价值。

8. 根据已完成的定义，在在场的整个团队中就故事的大小达成共识。
9. 验证您的评估在您进行过程中的各个故事之间是内部一致的。
10. 定期确保所有的1‘S是相同的，所有的2’S比赛，等等。
    • 同样，团队应该同意，四点故事的工作量大约是两点故事的两倍。