PART1 敏捷测试简介

一、敏捷测试的定义

敏捷的价值：持续地尽快交付客户可用的软件。

思想：测试驱动开发（TDD）。利用测试记录需求。

有效的敏捷是可重复的、高质量、高效的。

二、敏捷团队中的角色

客户团队-------------开发团队：测试人员在中间，既要了解客户的观点，也要了解技术实现的复杂性。

测试人员的职责：

1. 测试：自动化、系统、功能、性能、可用性、探索性等测试。面向业务的测试。

2. 协助：帮助客户清楚每个迭代中什么是对他们最有价值的。

3. 强调质量、文化。

三、敏捷团队

团队协作：鼓励以团队的方式来解决问题。

整个团队为质量负责。

每个人都可以寻求、获得帮助。

四、敏捷过程

每个迭代：1~4周。

第一步：编码前1-2天根据story编写测试用例。

第二步：开发、自动化测试同时进行。

第三步：测试+bugfix：同时进行。

第四步：验收测试。给业务培训功能。

开发人员向测试人员展示他们在做什么，测试人员向开发人员展示他们的测试用例。

五、敏捷测试原则

收集信息，向所有人提供项目进展的反馈。（持续）

乐于学习，有勇气提问。

以客户为中心，为客户创造价值。

持续改进。总结反馈，一次只关注一到两个核心问题。彻底解决。

拥抱变化。客户可能经常调整story优先级。自动化应对变化。

尽力促进沟通。关注人。

简单化。完成核心，再补充剩余功能。需求复杂时，简单的解决方案也会产生同样的价值。

六、敏捷文化

自由、独立思考、持续交流。要让每个成员对质量负责，需要给他们评估工作量，拒绝的权利。团队就敏捷达成一致。

合适的节奏。最好状态工作，而不是加班。

组织结构。自顶向下的交流渠道，不适合技术和业务的沟通。敏捷是大家提出问题，了解，帮助。

与固有文化冲突，压力下会选择旧方式。试点方式，请专家指导。培训、实验。制定规则，指导方针。

涉及关联系统提前计划，请求协助。无法得到帮助，寻求方法创新。

七、引入变化

应对变化时，要预先解释变化，设定期望模型。恐惧是正常的，可以接受的。

小小的成果认可，奖励。

测试人员有权提出任何需求、测试、代码的疑问。有权评估story的测试任务。

保持开放的思想，考虑你的团队有不同的观点。

提出的建议失败了，应再次提出并试用几个迭代 。

不在意一些小的缺陷，认识到修复缺陷的风险、代价可能大于缺陷。

如果需要管理层的时间、资金支持你学习，要向他们解释自动化的回归将提高团队工作效率，也会使每个迭代交付更多功能。

学习编码技能时，向开发同事请教，他们会认识到你渴望增长自己的技能。

非质量警察：请帮我找个解决方案，而不是“让这些人这么做”。

跟踪：

story的完成：sprint和燃烧图。

跟踪测试覆盖率。

八、团队构成

独立的测试团队，但测试人员在开发团队：没有偏见、了解技术、了解客户观点。

测试开发比例：

业务逻辑复杂，风险高，需要密集测试，更多测试人员。

业务简单，开发同事自己回归，可以不用测试人员。

story周期：开发+测试完成。

鼓励：开发-->提问，主动交流。寻求帮助，积极响应。

经理职责：解决资源、知识、环境、优先级、响应问题。