关于敏捷测试的那些事

今天听了下“段念”在INFOQ上一篇有关敏捷测试的演讲课程，听课笔记如下：

敏捷测试核心价值观：（交流、简单、反馈、勇气）
敏捷测试的要求：“交付可用产品”而非“发现缺陷”

传统：Requirements——>specifications——>code——>Testing——>Relese
Agile:Each story is expanded,coded and tested
         Possible release after each iteration

UI测试：API和业务适合自动化测试，已稳定的功能适合也适合使用，但UI新功能测试更建议使用手工测试；

敏捷带来的挑战：测试工程师应该做什么？测试工程师能够做什么？

敏捷测试核心：共享质量目标（工程师和测试均需要承担责任）
                           在产品中内建可测试性（是否适合自动化测试）
                           关注产品质量提升而非缺陷

测试工程师可以做什么：
获取和明确用户的质量期望
建立合适的系统测试、用户验收测试质量标准
让产品和代码质量反馈持续可见
推进单元测试（迫使开发对质量的重视）、开发测试、促进代码质量
建立与维护合适的自动化测试以减少测试的时间投入

测试工程师面临的挑战：
必须依赖于自己的沟通技巧与开发密切合作获取产品信息，制定测试计划而不是依赖文档
必须密切介入开发过程，参与设计
必须能够自我驱动
必须具有足够的自动化测试技能与探索性测试技能（随机测试）

解决方案：
与开发工程师密切合作
转变角色，变为“支持者”和“帮助产品具有更好质量的角色”
自我驱动。积极参与敏捷过程，主动工作
提升自己的技能，自动化测试、探索性测试、快速学习能力

测试团队面临的挑战：
考核标准需要变更
人员技能要求不同
测试过程管理需要转变
团队管理方式需要变更（传统：强调过程、文档，Agile：激励团队成员去做一切他们可以做的事情）

敏捷测试中，各个环节一般所占比例分配：
单元测试（70%） 集成测试（20%） UI测试（10%）

目前敏捷确实很火，特别是在互联网行业，敏捷开发，敏捷测试一直在提倡，都在转型，其实对于测试人员是一个比较大的挑战，需要测试人员掌握更多的技能，so 学无止境。

敏捷不一定适合每个公司，不能为了敏捷而敏捷，选择适合自己公司的测试流程和方法才是硬道理。