质量保证人员应如何准确地产生估计值？

Question

在我上一份工作中，我曾与一家从NO方法学到使用Scrum/Agile方法的公司合作。遇到了许多问题，包括Scrum“专家”真的不知道如何有效实施Scrum的事实。

他们使用的计划相对简单：
1.开始Sprint计划会议，其中QA和开发时间的估计值是一个估计值 - 不是QA时间和Dev时间的估计值。
2.当时间估计值达到Sprint的总数时，没有更多功能添加到该sprint中。

主要问题是QA通常不知道开发人员将如何编写代码...毕竟，他们不是编码人员！因此，质量保证团队确实没有任何基础来形成一个合理的时间估计。相反，99.9％的开发人员不知道理智测试，功能测试，回归测试和UAT测试之间的区别......所以他们无法准确估计某些功能需要什么QA时间。

最后我拿了一颗子弹我的QA团队，把这个问题向管理层，我在那里及时解雇不能够在Scrum的环境中工作，但是这确实不伦不类。

但它确实让我想知道错误在这里。难道我的问题是僵化的，想要在事情上付出艰辛的时间，还是QA应该天生知道应该花费多长时间来编写代码？

Answer 1

我想你们彼此交谈，并计算出两队之间的时间预算，然后提交管理层。

Answer 2

这并不回答你的问题，但在我看来，QA人员必须能够使用没有开发IDE的代码完成所有工作。了解设计，业务逻辑，如何闭环，设计测试等 - 都可以由QA人员完成。

Answer 3

我发现很好的工作是抵消开发/测试周期。所以你在一个迭代中编码，然后在下一个QA中编码。这使QA团队有时间适当地确定工作范围，而不是根据开发人员估算的估算。

Answer 4

我已经在质量保证和开发。这个过程在任何一个世界都没有太大的不同，因为它归结为一个简单的事情：所有的估计都是猜测。它们基于经验，预测，以及对特定问题的复杂性和风险的评估，但它们充其量是好猜测。

通过分析特定功能区域周围的一组已知任务，可以使它们更有用。在质量保证中，这意味着从您拥有的角度来看待问题：分析任何可能的用户故事中的变化，分析可能的输入，如果您有屏幕的模型等等。基于更好的猜测，手动或自动运行这些变化需要多长时间做一些基本算术。制作一个基于粗略等价类的一些关键场景的小二维矩阵，找出花费多少时间a）根据以前的经验为每个项目编写自动化测试，b）根据需要运行手动烟雾测试。

找出在预定的时间线期间需要多久运行一次这些测试。根据您判断中的错误概率（1.5倍，2.0倍，有时为3.0倍）以及确定正确的相对重要性运行乘数。如果真正重要的是您获得了经过良好测试的一项功能并且不太重要，那么需要对其他功能进行充分测试，然后相应地调整您的估算值，但在估算中确定该假设。

调度是关于管理风险，而不是消除它。它的目的是让您看到需要完成的事情。细节从来都不是很正确，没关系。我无法想象我曾经参与过的一个项目中，一切都按计划进行，特别是在开发方面。

敏捷不会改变那么多的方程;它确实改变了时间表。尽管存在教条，但确保在循环结束时进行测试还有一点空间，因为您还需要时间来解决不可避免会出现的问题。但你不必把它变成“迷你瀑布”;开发人员可以在所有功能都在工作的情况下继续工作，因为他们总是可以开始挑选迭代中优先级较低的任务。

我想知道，在您的情况下，开发团队是否代表您对QA进行了时间估算？让其他人打电话通常不是一个好主意。游戏中皮肤最多的人应该拥有最重的加权意见。但是很多开发人员可以做出相当好的风险评估，所以值得一听。在敏捷开发周期中，角色排他性应该比瀑布团队中的小，但我相当确信有些人只是在质量保证任务方面更好，他们自然会挑选大部分工作，即使在试图走敏捷的思想。如果你的问题是你不愿意在不知道实现细节的情况下做出估计，我可以说这是你需要克服的问题;即使在老派的方法论中，我也很少有完整的知识。

我想补充的一件事是：具有QA人才的人应该和他们的发展同行在同一个团队中。如果他们的职业发展是由不同的经理管理的，但是如果他们是不同的冲刺队伍的一部分则不好。因此，如果您有一个“测试团队冲刺”和一个“开发团队冲刺”，我认为您会削弱Dev和QA重点资源之间的协作和沟通潜力。