📅 最后修改于: 2020-12-07 05:23:33 🧑 作者: Mango
从每个团队成员都必须参与每个项目活动的意义上讲，Scrum提倡“整体团队方法” 。 Scrum团队正在自我组织，并对项目可交付成果负责。决策权留给团队，这导致在正确的时间采取适当的行动而没有任何时间延迟。这种方法还鼓励适当使用团队才能，而不是局限于一项活动。测试人员还参与所有项目和开发活动，从而贡献他们在测试方面的专业知识。
整个团队在测试策略，测试计划，测试规范，测试执行，测试评估和测试结果报告方面共同合作。
测试人员参与用户故事创建。测试人员会就系统可能的行为提出自己的想法。这有助于客户和/或最终用户了解实际环境中的系统，从而清楚地了解他们实际想要的结果。这样可以更快地冻结需求，并且还可以减少以后需求变化的可能性。
测试人员还会针对客户同意的每种情况提出验收标准。
测试人员有助于创建可测试的用户故事。
整个项目的发布计划已完成。但是，Scrum框架涉及迭代决策，因为在执行sprint的适当过程中可以获得更多信息。因此，在项目开始时的发布计划会议无需为整个项目制定详细的发布计划。只要有相关信息，它就可以不断更新。
每个sprint端都不需要发布。发布可以在一组冲刺之后进行。发布的主要标准是为客户提供业务价值。团队以发布计划作为输入来确定冲刺的长度。
发布计划是发布的测试方法和测试计划的基础。测试人员估算测试工作量，并计划发布的测试。当发布计划发生更改时，测试人员必须处理更改，并考虑更大范围的发布环境，以获得足够的测试基础。测试人员还提供所有冲刺结束时所需的测试工作。
冲刺计划是在每个冲刺开始时进行的。 sprint待办事项列表是使用从产品待办事项列表中挑选的用户案例创建的，以在该特定sprint中实施。
测试人员应该-
测试人员使用冲刺中测试工作量和持续时间的估算值更新测试计划。这样可以确保在短时冲刺期间为所需测试提供时间，并确保测试工作的可靠性。
当冲刺开始时，随着开发人员进行故事分析以进行设计和实施，测试人员将对冲刺积压中的故事进行测试分析。测试人员创建所需的测试用例-手动和自动测试。
Scrum团队的所有成员都应参与测试。
开发人员在为用户故事开发代码时执行单元测试。在编写代码之前，将在每个sprint中创建单元测试。单元测试用例源自低级设计规范。
测试人员执行用户故事的功能和非功能功能。
测试人员以他们在测试方面的专业知识指导Scrum团队中的其他成员，以便整个团队对产品质量负有集体责任。
在冲刺结束时，客户和/或最终用户执行用户验收测试，并向Scrum团队提供反馈。这形成了下一个冲刺的输入。
收集并维护测试结果。
在Scrum团队中，自动化测试非常重要。测试人员将时间用于创建，执行，监视和维护自动化测试和结果。由于Scrum项目随时可能发生更改，因此测试人员需要适应更改后的功能的测试以及所涉及的回归测试。自动化测试有助于管理与变更相关的测试工作。各个级别的自动化测试有助于实现持续集成。自动化测试的运行速度比手动测试快得多，而无需付出额外的努力。
手动测试更侧重于探索性测试，产品漏洞，预测缺陷。
测试活动的自动化减轻了重复工作的负担，并节省了成本。自动化
在一个Sprint中，测试人员测试该Sprint中新的/修改的代码。但是，测试人员还需要确保在早期sprint中开发和测试的代码也可以与新代码一起使用。因此，回归测试在Scrum中非常重要。自动化回归测试以连续集成方式运行。
Scrum项目中使用了使用自动化构建和测试框架的配置管理系统。当新代码被检入配置管理系统时，这允许重复运行静态分析和单元测试。它还管理新代码与系统的持续集成。自动回归测试在持续集成期间运行。
手动测试用例，自动测试，测试数据，测试计划，测试策略和其他测试工件需要受版本控制，并且需要确保相关的访问权限。这可以通过在配置管理系统中维护测试工件来实现。
Scrum团队中的测试人员可以遵循以下敏捷实践-
配对-两个团队成员坐在一起，共同工作。两个人可以是两个测试人员，也可以是一个测试人员和一个开发人员。
增量测试设计-随着Sprint的逐步发展和用户案例的添加，开发了测试用例。
在软件开发过程中，指标的收集和分析有助于改善流程，从而实现更高的生产率，质量可交付成果和客户满意度。在基于Scrum的开发中，这是可能的，并且测试人员必须注意他们需要的指标。
建议了几种Scrum开发指标。重要指标是-
成功冲刺的比率– (成功冲刺数/冲刺总数)* 100 。成功的冲刺是团队可以履行其承诺的冲刺。
速度-团队的速度取决于团队在冲刺过程中获得的故事点数。故事点是在估计期间计算的用户故事的量度。
专注因子– (速度/团队的工作能力)/ 100 。专注因子是团队努力完成故事的百分比。
估计精度– (估计工作量/实际工作量)/ 100 。估算准确性是团队准确估算工作量的能力。
Sprint Burndown-剩余Vs的工作量(以故事点或小时为单位)。理想情况下需要保留的工作(根据估算)。
如果更多，则意味着团队承担的工作量超出了他们的能力。
如果少于，则表示团队无法准确估算。
缺陷计数-Sprint中的缺陷数。缺陷数是相对于积压的软件缺陷数。
缺陷的严重性-根据缺陷的严重性，可以将缺陷分为轻微，严重和严重。测试人员可以定义分类。
在Sprint回顾中，所有团队成员都将参加。他们分享-