敏捷项目测试策略文档模板
在一个敏捷工作环境种，我们的研发工作以冲刺期和高度迭代的形式展开。每一个迭代周期都关注少数的需求或者用户故事，所以在文档在敏捷项目种的数量和内容方面都倾向于轻量化。
对于测试计划这样的文档也是如此，不过我们也确实需要为敏捷团队去提供一个概要的敏捷测试策略，以供指导。
敏捷测试策略文档是为了给团队提供一个最佳的测试实践和一些形式的测试体系。记住，敏捷并不意味着没有体系。
下面我们来看一个敏捷测试策略文档，看看我们都应该包含些什么内容。
1. 一份测试策略中通常都会对于更宽泛的商业目的和目标做出任务说明。
一个典型的任务说明可以是：
“通过快速反馈和缺陷预防，持续的交付可工作的，满足用户需求的软件，而不仅仅是缺陷发现”
细化以后：
“● 在定义完需求的接收条件/测试之后，代码才能进行编写。
● 接收测试不通过，一个需求就不能被判断为完成。”
在敏捷项目中，通常还会包含关于质量保证的提示：
● 质量保证是系统和可靠的保证产品满足用户需求的一系列活动。
● 在SCRUM（敏捷）中，质量保证是所有人的责任，而不单单是测试人员。在我们开发新产品的过程中，我们通过质量保证活动来确保正确的质量。
2. 测试级别
2.1 单元测试
WHY: 确保代码被正确开发
WHO: 开发工程师/技术架构师
WHAT: 所有新代码+历史代码的重构+javascript单元测试
WHEN: 一旦有代码被编写
WHERE: 开发本地环境+持续集成环境
HOW: 自动化, Junit, TestNG, PHPUnit
2.2 接口测试
WHY: 确保组建之间的交互正常工作
WHO: 开发工程师/技术架构师
WHAT: 新的web services, 组件, 控制器, 等
WHEN: 一旦新接口开发准备完毕
WHERE: 开发本地环境+持续集成环境
HOW: 自动化, Soap UI, Rest Client
2.3 接收测试
WHY: 确保用户需求已达成
WHO: 开发/测试开发工程师/手工测试
WHAT: 对需求进行接收测试，验证产品特性
WHEN: 当产品特性已被开发完成并通过单元测试
WHERE: 持续集成环境/测试环境
HOW: 自动化(Cucumber)
2.4 系统测试/回归测试/用户接收测试
WHY: 确保系统整体集成后工作正常
WHO: 测试开发工程师/手工测试/商务分析/Product Owner
WHAT: 场景测试，用户流程和典型用户旅程，性能和安全测试
WHEN: 当接收测试完成后
WHERE: 预生产环境
HOW: 自动化(Webdriver) ，探索性测试
3. 产品代办列表
软件开发失败最常见的原因，是因为需求的不明确和团队不同成员对需求的不同解读。
用户故事应该简单，精炼避免含糊不清。做为一个好的指导，在编写用户故事时最好遵从INVEST模型。
一个好的用户故事应该：
独立(与其他的故事)
可讨论(不是某个软件特性的具体协议)
有价值的
可估算的
体积小(可被一次迭代完成)
可测试
编写用户故事时应该遵从以下格式：
做为一个[角色]
我想要[功能/特性]
来[达成什么目标]
注意不要遗忘“达成目标”部分，这样所有人都知道开发这个需求的时候我们为产品增加了什么价值。
接收条件：
每个用户故事必须包含接收条件。这也许是最重要的要素，它能促使团队成员就需求进行交流。
接收条件应该在用户故事编写的同时被定义完成，并且应被包含在故事内。所有的接收条件必须是可测试的。
每个接收条件应该展示一些接收测试范例，可以是使用Gherkin格式撰写的一些场景，比如：
场景1: 标题
Given[上下文/背景]
And[更多条件]...
When[事件/动作发生]
Then[产生结果]
And[更多结果]...
4. 开发测试
做为开发，我们应该表现得像组织内不存在测试人员一样去开展工作。确实QA会有不一样的测试思维，但是开发也应该尽其所能的去测试。
开发可能认为尽快的去进行下个需求的开发是节省了自己的时间，但是在实际中，如果一个缺陷被发现并且报告了，比起在开发阶段去验证功能是否正常工作要花去你更多的时间。
任何新开发的代码和对于历史代码的重构都应该有足够的单元测试，这些单元测试应该是单元回归测试的一部分。
5. 自动化接收测试和非功能性测试
自动化接收测试包括集成测试和服务测试以及用户界面测试，目标是确认软件在功能性上工作正常，并且满足用户的需求和规格。
自动化接收测试可以采用Gherkin语言编写，使用类似于Cucumber的BDD工具来执行。
记住：并不是所有测试都要实现自动化！
非功能性测试（性能和安全性等）与功能性测试是同等重要的，所以在每次部署时需要被测试。
性能测试应在每次部署时关注系统性能指标，防止系统性能滑坡。
应使用OWASP来确保系统的基本安全性指标。
重要的是这些应该是完全自动化的流程，不需要太多维护工作，结合自动化构建部署来达到最佳收益。这意味着不能有间歇性测试失效，测试脚本问题和环境问题。
任何失效都应该是真实的代码缺陷而不是脚本问题，所以任何不是由于真实代码缺陷引起的问题都应该被立即从自动化包里修复或移除，这样可以得到持续性结果。
6. 回归测试
我们不期望在回归测试中发现很多缺陷。回归测试的目的是提供反馈，让我们确定重要功能未被破坏。手工回归测试工作量应该很低。
冒烟测试 - 不应超过15分钟
冒烟测试包仅包含重要的功能，以确定产品对于后续开发和测试工作而言是足够稳定的。
例如，对一个电子商务网站，冒烟测试应该包括：
- 商品搜索
- 商品查看
- 商品购买
- 注册/登录
整体回归测试 - 不应超过1个小时
整体回归测试包，包含了所有的回归测试用例以及在冒烟测试中没有涵盖的内容。
在这里，我们的目标是得到更大体积测试的快速反馈。如果这种反馈超过1个小时，那么就不够快速。要么我们可以使用结对测试的方法来减少测试数量，要么根据风险来排序测试，要么让测试并发执行。
7. UAT和探索性测试
UAT和探索性测试没有理由不能与自动化测试一起执行。毕竟，他们是不同的测试活动，关注于不同的测试目标和问题。UAT的目标是确保开发的功能/特性对于客户而言是商务上合理的且有帮助的。
产品所有者（PO）应该执行用户接收测试（UAT）或者商务接收测试，以确定产品满足用户期望。
探索性测试应该关注于用户场景，并且找到自动化测试遗漏的问题。探索性测试应该发现琐碎问题而不是大问题。
8. 完成标准
一旦所有以上活动都完成了，并且没有发现问题，那么需求就完成了。
以上是对于一个敏捷测试策略文档可以包含内容的指导。显然当你用于自己的项目和组织时是需要进行调整的，但是希望，这个模板可以帮助你去创建自己的敏捷测试策略文档。
译自：https://www.testingexcellence.com/agile-test-strategy-example-template/