methodology - QA 人员应该如何准确地进行估算？

Question

在我的上一份工作中，我与一家公司合作，该公司正在从没有方法论转向使用 Scrum/敏捷方法。遇到了很多问题，包括 Scrum“专家”真的不知道如何有效地实现 Scrum。

他们采用的方案比较简单:
1. 开始 Sprint 计划 session ，其中 QA 和 Dev 时间的估计是一个估计 - 一个不是 QA 时间，一个是开发时间。
2. 当估计时间达到 Sprint 的总时间时，不再向该 Sprint 添加任何功能。

主要问题是 QA 通常不知道开发人员将如何编写代码……毕竟，他们不是编码员!所以 QA 团队真的没有依据来形成一个体面的时间估计。相反，99.9% 的开发人员不知道健全性测试、功能测试、回归测试和 UAT 测试之间的区别……因此他们也无法准确估计某些功能需要多少 QA 时间。

最终，我为我的 QA 团队挡了一颗子弹，并将这个问题交给了管理层，在那里我因无法在 Scrum 环境中工作而被迅速解雇，但这实际上既不存在也不存在。

但这确实让我想知道这里的错误是什么。是我的问题很僵化并且想要在事情上艰难地度过，还是期望 QA 应该天生就知道应该花多长时间来编码？

Answer 1

我一直在 QA 和 Dev。这个过程在任何一个世界都没有太大的不同，因为它归结为一个简单的事情:所有的估计都是猜测。它们基于经验、预感以及对一组特定问题的复杂性和风险的评估，但它们充其量只是很好的猜测。

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

弄清楚在预定的时间线内您需要多久运行一次这些测试。根据您判断中的错误概率(1.5 倍、2.0 倍，有时是 3.0 倍)以及正确处理的相对重要性来运行乘数。如果对一个功能进行良好测试确实很重要，而对另一功能进行良好测试不太重要，则相应地调整您的估计，但在您的估计中确定该假设。

调度是关于管理风险，而不是消除风险。它旨在让您对需要完成的工作有一个全面的了解。细节永远不会完全正确，这没关系。我想不出有一次在我参与的项目中，一切都按计划进行，尤其是在开发方面。

敏捷并没有太多地改变方程式；它确实稍微改变了时间线。尽管存在反对的教条，但最好确保在周期结束时有一点空间进行测试，因为您还需要开发时间来解决不可避免地出现的问题。但是你不必把它变成“迷你瀑布”；开发人员可以在所有功能都正常工作的情况下继续工作，因为他们总是可以开始挑选迭代中优先级较低的任务。

我想知道，就您而言，开发团队是否代表您进行了 QA 时间估算？让其他人来决定这通常不是一个好主意。游戏中拥有最多皮肤的人应该拥有最重要的意见。但是很多开发人员可以做出很好的风险评估，因此当然值得倾听他们的意见。在敏捷开发周期中，理想情况下，角色排他性应该比瀑布团队中的要小，但我相当相信有些人只是更擅长 QA 任务，他们自然会选择大部分工作，即使在一个试图走敏捷的意识形态。如果您的问题是您不愿意在不了解实现细节的情况下进行估算，我可以说这是您需要克服的问题；即使在老派的方法论中，我也很少拥有完整的知识。

我要补充的一件事是:具有 QA 人才的人员应该与他们的开发人员在同一个团队中。如果他们的职业发展由不同的经理管理是可以的，但如果他们属于不同的 sprint 团队则不行。因此，如果您有“测试团队冲刺”和“开发团队冲刺”，在我看来，您正在削弱以开发和 QA 为重点的资源之间的协作和沟通潜力。