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