问Scrum中的质量保证(测试)

EN

测试和质量保证是如何为scrum工作的？(因此生产中的bug发生率很低。)

实际上，我不认为SCRUM解决了这个问题。SCRUM并不涵盖产品/项目的所有阶段。SCRUM主要是组织开发本身-从“我们有一个特性的想法”到“开发团队认为这是生产准备好”的部分。它没有涵盖项目的第一部分(基本思想、项目愿景、寻找利益相关者、获得预算.)，也不包括最终交付(部署、客户反馈等)。

因此，如果您觉得在SCRUM团队完成之后还需要一个额外的阶段，那么在投入生产之前，一定要有一个单独的QA测试、回归测试、认证和测试阶段。

您仍然可以获得频繁发布的价值，因为需要测试一些内容并从涉众那里获得反馈--但是仅仅因为您想要反馈并不意味着您必须向客户发送信息(尽管这通常是有用的)。请注意，SCRUM提到了“潜在的可移植产品”，因为您可能出于各种原因实际上不想发布该产品。

注意:很明显，单独的QA/测试阶段的缺点是实际上需要更长的时间才能将一个功能交付给客户。但是，如果质量比快速发布新特性更重要，那么这可能是正确的折衷--这取决于涉众和开发人员。

在Scrum中，每个历史都有一个完成的定义，如果一个历史被认为是“完成”的，那么它就是因为实现了这个定义而准备投入生产的。如果您经常有产品错误，您必须在“完成”的更好定义中工作，并确保历史记录满足此定义。

Scrum是唯一的轻量级项目管理技术，当像您这样的难题出现时，scrum通常没有具体的答案。您需要在其他敏捷方法中找到这些答案(比如从极限编程中进行TDD或对编程)。例如，您的所有用户历史必须传递的be的一般定义可以是这样的：

• 所有单元测试合格证及其修订的覆盖范围
• 代码被修改了(我们更喜欢对编程，这只是一个例子)
• 它在测试服务器中部署的特性。
• 由QA人员修改的特性。
• 负载测试
• ..。

您可以添加您想要的任何内容，关键是必须确保满足此定义的用户历史符合项目所需的质量级别，并且可以投入生产。

关于QA只有两件事

• QA人员不能是单独的团队，QA人员是团队的一部分。scrum团队需要所有的技能来实现DoD。
• 如果您的自动测试(TDD或非TDD)不足以达到您需要的质量水平，那么您需要考虑如何更好地进行自动测试，那么QA人员可能会帮助您实现这一自动化。如果您需要执行长时间(可能是几天)的手动回归测试，那么快速发布是不可能的，如果您没有自动化(或半自动化，但非常快速)的方法来确保某种产品能够以所需的质量水平投入生产，scrum就不能给您快速发布。

如果您正在实践测试驱动开发，scrum可以是无缺陷的，因为您向您的V&V团队发布的软件满足了您的单元测试所提出的所有期望。

换句话说，您可能无法证明您的软件没有bug，但您可以证明它通过了所有的单元测试。单元测试是主管或经理可以签署的内容。这不是一个医疗等级的认证(你仍然需要质量保证)，但它确实减轻了你的团队的负担，证明是无缺陷的状态。

因此，与其在每个版本上声称没有错误的软件(这一断言可能是不正确的)，您还可以证明所批准的Unit测试在其商定的范围内是可靠的。

您还可以在将软件发布给QA之前对其进行功能测试。QA可以帮助您开发一些或所有这些测试。

进一步阅读

http://en.wikipedia.org/wiki/Therac-25

Therac 25是一个很好的案例研究，因为开发过程中的问题(而不是被发现的几个特定的软件错误)被认为是失败的主要原因。