敏捷测试、Scrum 和 eXtreme Programming
4.95/5 (6投票s)
敏捷团队作为一个整体，朝着实现质量的共同目标而努力。
目录
引言
Scrum 是一种软件开发过程。在当今快速发展的世界中，利益相关者希望立即获得投资回报。他们不想等待更长时间来获得功能齐全的产品。因此，如今一种新的软件开发和测试框架正风靡起来，即 Scrum 方法。
在Scrum 中，项目被划分为在称为Sprint（小周期）的特定时间范围内开发和测试的小功能。功能应在指定的小时间范围内进行开发和测试。这个敏捷 Scrum 团队由Scrum Master 管理。
Scrum 是一个迭代、增量的项目和产品或应用程序开发框架。Scrum 已成为组织中越来越流行的软件开发和测试框架。从小型到大型的 IT 公司都开始采用 Scrum 框架，因为与传统的其他方法相比，它可以在更短的时间内创建出色的高质量产品。该框架可以为公司节省时间和金钱。
Scrum 团队的必备软技能
团队精神
跨职能团队协作是 Scrum 的核心。没有“我的工作”、“我已完成我的工作”和“你的工作”。在 Scrum 团队中，我们只有“我们的工作”、“我们已完成我们的 Sprint”。个人会倾向于乐于分享技术知识。Scrum 成员始终为团队成员提供帮助，而不是把自己封闭起来。Scrum Master 将始终激励团队并创造一个支持性的学习环境。团队将始终面向 Sprint，并经常讨论 Sprint 的顺利运行。Scrum 团队的工作是围绕挑战进行自我组织，而管理的职责是消除阻碍自我组织的障碍。
沟通
开发团队、测试团队、业务分析师和利益相关者之间的团队成员之间必须存在良好的沟通。客户与交付团队之间必须有高度的协作互动。更多的客户参与意味着客户会提出更多的建议或变更。这意味着需要更多的沟通带宽。
承诺
敏捷团队需要周期性地重新注入活力，以重申他们对目标的承诺和彼此之间的承诺。Scrum Master 可以通过确保团队拥抱全团队责任和全团队承诺的概念，在每个 Sprint 结束时交付可工作的软件来提供帮助。有了全团队的承诺，完成任务的团队成员将帮助未完成任务的成员，从而希望每个人都能按时完成。
解决问题
Scrum 不仅仅专注于开发任何类型的最终产品。相反，Scrum 方法允许团队专注于创建满足客户最高价值优先级的产品，这些优先级由产品负责人定义。
透明度
团队成员和管理层之间的透明度为 Scrum 团队带来了真正的动力。Scrum Master 鼓励人们寻求帮助，提出阻碍，并公开表扬那些敢于这样做的人。同时，Scrum Master 也理解当个人隐瞒或忽视问题时所浪费的时间以及对团队造成的影响。
Scrum 的角色
Scrum 有三个基本角色：产品负责人、Scrum Master 和团队成员。
- 产品负责人：在 Scrum 中，产品负责人负责将产品的愿景传达给开发团队。他/她还必须通过需求和优先级来代表客户的利益。由于产品负责人拥有这三个角色中最大的权力，因此它也是责任最大的角色。换句话说，产品负责人是项目失败时必须承担后果的唯一个人。权力与责任之间的张力意味着产品负责人很难在参与度上取得适当的平衡。由于 Scrum 重视团队的自我组织，因此产品负责人必须克服微观管理的冲动。同时，产品负责人必须随时回答团队的问题。
- Scrum Master：Scrum Master 在产品负责人和团队之间充当联络人。Scrum Master 不管理团队。相反，他/她致力于消除任何阻碍团队实现 Sprint 目标的障碍。简而言之，这个角色有助于团队保持创造性和生产力，同时确保其成功对产品负责人可见。Scrum Master 还致力于就如何为团队最大化投资回报向产品负责人提供建议。
- 团队成员：在 Scrum 方法中，团队负责完成工作。理想情况下，团队由七名跨职能成员组成，加减两名。对于软件项目，典型团队包括软件工程师、架构师、程序员、分析师、QA 专家、测试人员和 UI 设计师的组合。每个 Sprint，团队负责确定如何完成工作。这赋予了团队很大的自主权，但与产品负责人一样，这种自由伴随着实现 Sprint 目标的责任。
核心流程
Sprint 计划会议
Sprint 中要执行的工作在 Sprint 计划会议上进行计划。该计划由整个 Scrum 团队通过协作工作创建。Sprint 计划会议对于一个月 Sprint 的时间限制为八小时。对于较短的 Sprint，活动相应缩短。例如，两周 Sprint 有四小时的 Sprint 计划会议。
Sprint 计划会议包含两个部分，每个部分的时间限制为 Sprint 计划会议时长的二分之一。Sprint 计划会议的两个部分分别回答以下问题：
- 在即将到来的 Sprint 产生的增量中将交付什么？
- 将如何完成交付增量所需的工作？
第一部分：本次 Sprint 将完成什么？
在这一部分，开发团队致力于预测将在 Sprint 中开发的的功能。产品负责人将排序后的产品待办事项列表项呈现给开发团队，整个 Scrum 团队共同理解 Sprint 的工作。本次会议的输入是产品待办事项列表、最新的产品增量、开发团队在 Sprint 期间的预期容量以及开发团队过去的绩效。从产品待办事项列表中为 Sprint 选择的项目数量完全由开发团队决定。只有开发团队才能评估其在即将到来的 Sprint 中可以完成的工作。开发团队预测将在 Sprint 中交付的产品待办事项列表项后，Scrum 团队将制定 Sprint 目标。Sprint 目标是通过实现产品待办事项列表将在 Sprint 中实现的目标，它为开发团队提供了有关为何构建增量的指导。
第二部分：如何完成选定的工作？
在选择了 Sprint 的工作后，开发团队决定如何在 Sprint 期间将这些功能构建成“完成”的产品增量。为本次 Sprint 选择的产品待办事项列表项加上交付它们的计划称为 Sprint 待办事项列表。开发团队通常首先设计系统和将产品待办事项列表转换为可工作产品增量所需的工作。工作的大小或估计的工作量可能不同。然而，在 Sprint 计划会议期间，计划了足够的工作，以便开发团队能够预测其在即将到来的 Sprint 中可以完成的工作。到本次会议结束时，开发团队将要完成的 Sprint 工作已分解为一天或更少的工作单元。开发团队会自我组织以承担 Sprint 待办事项列表中的工作，包括在 Sprint 计划会议期间以及在整个 Sprint 期间根据需要进行。产品负责人可以参加 Sprint 计划会议的第二部分，以澄清选定的产品待办事项列表项并帮助进行权衡。如果开发团队确定工作量过多或过少，它可以与产品负责人重新协商 Sprint 待办事项列表项。开发团队还可以邀请其他人参加，以提供技术或领域方面的建议。到 Sprint 计划会议结束时，开发团队应该能够向产品负责人和 Scrum Master 解释其将如何作为自我组织的团队工作，以实现 Sprint 目标并创建预期的增量。
Sprint 目标
Sprint 目标为开发团队在 Sprint 中实现的具体功能提供了一定的灵活性。在开发团队工作时，他们会牢记此目标。为了满足 Sprint 目标，他们会实现功能和技术。如果工作证明与
开发团队的预期不同，那么他们将与产品负责人合作，在 Sprint 中协商 Sprint 待办事项列表的范围。Sprint 目标可能是产品路线图更大目标的一个里程碑。
每日 Scrum
每日 Scrum 会议是一个 15 分钟的时间盒事件，供开发团队同步活动并制定未来 24 小时的工作计划。这是通过检查自上次每日 Scrum 以来的工作以及预测在下次会议之前可以完成的工作来完成的。每日 Scrum 每天在同一时间和地点举行，以降低复杂性。在会议期间，每位开发团队成员会解释：
- 自上次会议以来完成了什么？
- 下次会议之前将完成什么？
- 有什么障碍？
开发团队使用每日 Scrum 来评估 Sprint 目标的进展情况，并评估完成 Sprint 待办事项列表工作的趋势。每日 Scrum 优化了开发团队满足 Sprint 目标的可能性。开发团队通常在每日 Scrum 之后立即开会，以重新规划 Sprint 的其余工作。每天，开发团队都应该能够向产品负责人和 Scrum Master 解释他们将如何作为自我组织的团队协同工作，以在 Sprint 的剩余时间内实现目标并创建预期的增量。Scrum Master 确保开发团队举行会议，但由开发团队负责进行每日 Scrum。Scrum Master 教导开发团队将每日 Scrum 控制在 15 分钟的时间盒内。Scrum Master 执行只有开发团队成员参加每日 Scrum 的规定。每日 Scrum 不是状态会议，而是供将产品待办事项列表项转化为增量的人员进行的。每日 Scrum 改进沟通，消除其他会议，识别并消除开发障碍，突出并促进快速决策，并提高开发团队的项目知识水平。这是一个关键的检查和调整会议。
Sprint 评审
Sprint 评审会议在 Sprint 结束时举行，以检查增量并根据需要调整产品待办事项列表。在 Sprint 评审期间，Scrum 团队和利益相关者将协作讨论 Sprint 中完成的工作。基于此以及 Sprint 期间产品待办事项列表的任何更改，与会者将协作讨论接下来可以做什么。这是一个非正式的会议，增量的演示旨在征求反馈并促进协作。对于一个月的 Sprint，这是一个四小时的时间盒会议。对于较短的 Sprint，分配的时间相应较少。例如，两周 Sprint 有两小时的 Sprint 评审。
Sprint 评审包括以下要素：
- 产品负责人确定“已完成”和“未完成”的内容；
- 开发团队讨论 Sprint 期间的进展情况、遇到的问题以及如何解决这些问题；
- 开发团队演示已“完成”的工作，并回答有关增量的问题；
- 产品负责人讨论当前的产品待办事项列表。他/她根据迄今为止的进展预测可能的完成日期；以及，
- 整个团队协作决定下一步要做什么，以便 Sprint 评审为后续的 Sprint 计划会议提供有价值的输入。
Sprint 评审的结果是修订后的产品待办事项列表，该列表定义了下一个 Sprint 的可能产品待办事项列表项。产品待办事项列表也可能进行整体调整以适应新的机遇。
Sprint 回顾
Sprint 回顾是 Scrum 团队审视自身并制定改进计划的机会，以在下一个 Sprint 中实施。Sprint 回顾在 Sprint 评审之后、下一个 Sprint 计划会议之前举行。对于一个月的 Sprint，这是一个三小时的时间盒会议。对于较短的 Sprint，分配的时间相应较少。
Sprint 回顾的目的是：
- 审视上一个 Sprint 在人员、关系、流程和工具方面的情况；
- 识别并排序重要的进展情况和潜在的改进点；以及，
- 制定实施改进 Scrum 团队工作方式的计划。
Scrum Master 鼓励 Scrum 团队在 Scrum 流程框架内改进其开发流程和实践，以便在下一个 Sprint 中使其更有效、更愉快。在每次 Sprint 回顾期间，Scrum 团队会通过适当调整“完成”的定义来计划提高产品质量的方法。到 Sprint 回顾结束时，Scrum 团队应该已经确定了将在下一个 Sprint 中实施的改进。在下一个 Sprint 中实施这些改进是对 Scrum 团队自身检查的适应。尽管改进可以在任何时候实施，但 Sprint 回顾提供了一个专注于检查和调整的专用活动。
开发和测试齐头并进
Scrum 中的质量保证活动
Scrum 是一种管理方法。它有一些重要的管理规则和实践，管理层可以利用这种方法论来获得帮助，以组织和更好地处理其流程。因此，它不是一种具有某些已定义质量保证活动的工程流程。管理层可以自行引入任何活动来获得高质量的产品。Ralph van Roosmalen 博士说，Scrum 是一个项目管理框架，它不包含任何关于测试或开发实践的帮助。大多数使用 Scrum 的公司将其与 XP（极限编程）结合使用。这样，Scrum 辅助项目管理，XP 的实践用于指导开发。
Scrum 中的工作步骤是：
- 单元测试
- 持续集成
- 定期 Sprint 会议
- 定期每日会议
- 严格遵守编码和设计标准
- 验收测试
- 测试自动化
- 探索性测试
迭代生命周期和频繁沟通是 SCRUM 中对测试人员重要的方面。这两者都需要测试人员方面的一些调整，他们可以牢记一些事情。产品测试在迭代期间进行，而不是在开发生命周期结束时进行。测试人员有责任决定在产品尚未完成时测试什么。Scrum 的核心是团队合作，协作是基本理念。因此，强烈建议测试人员与其团队成员密切合作，而不是孤立工作。测试人员应积极参与每日会议，并参加每日状态会议，会议最长为 15 分钟。从测试人员的角度来看，如果他们与其他测试人员合作，找出要测试的内容，而不是从需求文档中测试，那么这是有价值且面向质量的。
敏捷测试流程的最佳实践
- 将测试人员整合到开发团队中
- 使用基于风险的测试
- 让测试人员评审单元测试
在我们组织中，开发人员负责创建和维护单元测试。单元测试是我们测试工具链的一个非常重要的组成部分。开发人员的思维方式通常不同；例如，他们倾向于只测试成功场景。为了创建尽可能好的单元测试，我们的测试人员会评审我们所有高风险项的单元测试。评审有两个优点。首先，单元测试得到了改进，因为测试人员和开发人员可以互相补充：开发人员知道源代码的薄弱环节在哪里，而测试人员可以利用其测试知识提供改进单元测试的建议。其次，测试人员确切地知道单元测试中执行了哪些测试用例，并且可以专注于执行其他（例如，更高级别的）测试用例。
- 创建测试自动化框架并任命一名工具匠
- 在公共场所显示质量指标
- 添加测试 Scrum
- 实施测试回顾
- 计划未解决的问题
- 记住：测试仍然是测试
- 开始做！
团队负责交付满足预期需求和质量的软件。然而，如果我们希望团队测试软件，就必须让他们拥有正确的知识。测试人员拥有这些知识。通过将测试人员整合到开发团队中，团队获得了测试其软件所需的技能。尝试这样做时，请确保选择合适的比例：三名程序员配备一名测试人员是一个公平但最低的要求。
即使在瀑布式项目中，您也无法以相同的（广泛）深度测试所有内容；您都必须做出选择。在敏捷项目中，所有活动都是时间盒的，因此您必须就每个功能要测试的深度做出选择。我们使用基于风险的方法来确定在迭代期间为功能执行哪些测试活动。每个功能的风险级别由客户和团队确定。这是一个非常透明的过程，因此客户确切地知道为每个功能执行了哪些测试活动。
自动化测试非常重要，因为新功能和重构可能会引入难以发现的问题。通过使用自动化测试框架，我们可以在迭代期间保持质量水平。我们的测试人员可以在框架中轻松快速地创建新测试。我们有一名专职测试工程师（我们称他为工具匠），负责维护和优化测试自动化框架，评审测试人员的新自动化测试，并分析每日测试结果。团队中的测试人员可以花费更多时间创建和扩展自动化测试，因为工具匠为他们提供支持。
几乎所有软件项目都有问题注册系统、自动化测试结果，在某些情况下还有夜间或持续构建结果。但是团队成员多久查看一次结果或计算未解决的问题数？我们在休息室安装了一个显示器，显示当前未解决问题的实际指标、成功单元测试的百分比、成功夜间构建的百分比以及持续构建的当前状态。通过在公共场所显示指标，团队就会接触到这些信息。这些信息不再仅仅是一个系统中的数字或一个包含指标数据库中一些信息的记录。
将单独的测试团队安排在一个房间的好处是测试人员之间的沟通良好。当您有一个项目，例如我们的项目，测试人员分布在多个团队中时，沟通就会变得更加困难。为了解决这个问题，我们使用测试 Scrum 来协调测试活动。我们的测试 Scrum 每周举行两次，每个团队由一名测试人员代表。测试 Scrum 类似于每日团队 Scrum，但专注于测试活动。测试经理是测试 Scrum 的 Scrum Master。
我们项目中的每个团队都会在迭代结束时举行回顾会议。在回顾会议中，团队讨论流程：哪些进展顺利，哪些进展不顺利。团队中的测试人员可以学习并发现改进其测试的新方法；让他们与其他团队的测试人员分享这些知识是很好的。我们每个迭代都会进行一次测试回顾，以便测试人员可以交流知识和经验，并讨论他们遇到的问题。重要的是，回顾会议仅与测试问题相关；您不应讨论团队问题（这些问题应在团队回顾会议中讨论）。与测试 Scrum 一样，测试经理是测试回顾的 Scrum Master。
我们试图在同一迭代中修复在迭代期间发现的所有问题，但有时我们会带着未解决的问题结束迭代。处理这些问题的最佳方法是将这些问题添加到下一个迭代的 Sprint 待办事项列表中。通过明确计划这些问题，它们被“遗忘”并堆积起来的可能性非常小。
当您在敏捷软件项目中进行测试时，您仍然可以使用“传统”的测试技术。我们使用探索性测试，但也应用边界值分析、等效划分、因果图和成对测试等测试技术。我们为某个功能选择哪种测试技术取决于其风险类别。探索性测试在每个类别中使用；但如果风险较高，我们还会应用更正式的测试技术。对测试人员来说，挑战在于使用正式的测试技术而不提供大量的测试文档。
最后一个也是最重要的建议是开始做！不要过多地谈论您将如何引入测试人员，或者哪种测试方法适合您的组织。您会犯错误，或者发现所选方法不适合您的组织。这是必然的。但是，您开始得越早，就能越早开始学习和改进您的测试方法。通过回顾会议，您有机会每个月调整您的测试方法。