敏捷测试

敏捷测试

敏捷已经开始流行，很多情况下，敏捷只是稍微改变了团队的运行情况，本身也没有任何固定的方法论，敏捷到底能够带来什么呢？
首先，是思想层面上的，最主要的就是拥抱变化，快速变化。从这个层面出发，有很多的方法也随之而来，但是本质上开发团队需要做的事情
被没有改变什么？开发团队需要做的以下内容：
- 需求澄清
- 开发时间估算
- 开发设计
- 编码，单元测试
- 模块测试，集成测试
- 重构
。。。。。。。。。。。。。
这些内容实际上被没有改变，但是改变的是，团队不需要交付一个完美的产品，但是需要一个在某个时间周期内可以接受的产品。

在整个开发过程中，一切都可以商量，单元测试是不是必须，长期来看是必须的，但是在一个很短的时间内？测试是不是必须的？
个人认为都可以商量，主要看达成什么样的目的？团队是否能够达成一致。

比如说从单元测试的角度来说，这个其实是必须的，关于一个任务的完成不仅仅表示说代码完成，实际上是开发活动全部完成才算，包括
单元测试，模块测试，集成测试，性能测试。。。。。。。。；往往开发不愿意做单元测试，觉得不提供价值或者是测试需要做的，其实
如果从这个点出发，那么从敏捷的角度来说，这个团队就不是敏捷团队了。说服开发进行单元测试其实是一个非常困难的事情，往往团队的话语
权在开发，但是开发并不见得拥有足够的质量观念，依然停留在测试都是测试的事情上面，那么产品质量肯定会出问题的。更长远一点来说，
如果没有单元测试，那么以后遗留系统做重构，开发你敢下手吗？多少这样的事情，当时说单元测试延后，但是一般延后了，就没有然后了。

好的公司，好的开发其实都是做单元测试的。前面一家公司可以说是我呆过的最好的公司，里面开发都是有单元测试的，
一个敏捷team，3个开发1个测试，负责整个网站平台的一个核心业务。线上所有的交易几乎都和这个模块相关，每天交易额也在百万美元级别了。
整个team也许交付的东西不需要非常非常多，但是交付的节奏是一定要有的。一个可以预期的交付，比随意交付一堆东西要来的有价值。

Team的目标是交付高价值，高质量的产品，而不是交付代码给测试，让测试通过。
敏捷团队使用的核心实践，其实都是和测试有关系，TDD，CI。。。。。。，所以高效的敏捷团队，离不开敏捷测试。

那么什么是敏捷测试呢？面向业务的测试，同时也包括了功能，性能，安全。。。。。。。，几乎无所不包。

测试人员，在里面可以激化更多的需求分析，用例分析，但是对于测试来说，还需要考虑一点，到底是你的技能让你能这样子做呢，还是你的身份？

敏捷测试有何不同

从软件测试人员真的能够质量吗？这个问题开始，我的答案是不能，有这样的期望是好事，但是一般都是老板的一厢情愿。同时高估了测试的能力，
基本上对于团队不一定有什么好处。所谓测试对质量负责，其实都是假象，一个他没有权利负责，另外可能也在他的能力范围之外了。

那么既然如此，测试人员在敏捷团队里面能做什么呢？
- 需求确认分析
- 探索性测试
- 不同于单元测试的方法
- 反应客户需求的测试

总之所有测试活动都不应该完全是测试的任务，而是team的任务，每个人都应该把测试观念放到每个环节里面。

敏捷测试人员10条法则

• 每一个人都是敏捷测试人员，态度高于技能，关注客户，关注价值
• 收集，分析信息，提供反馈，提供关于需求的反馈
• 关注最总要的核心功能，关注关键路径
• 勇气： 寻求帮助
• 总结，反馈，持续改进

组织文化

• 整体团队负责质量，如果质量有单一的部门或者团队负责，都有可能达不到目的
• 合适的工作节奏
• 沟通挑战， 领域专家，测试沟通
• 对于如何实现敏捷达成一致
• 测试权利法案：
  
  • 你有权利在任何时候提出关于测试，质量和过程的问题
  • 你有权利向客户，程序员和其他测试团队提出问题
  • 你有权利请求并从项目团队中的任何一个人获得帮助
  • 你有权利评估测试任务并将这些包含到用户故事中
  • 你有权利及时获得执行测试任务时需要的工具
  • 你有权利期望你的整个团队，而不是仅仅你自己为质量负责

团队结构

• 是否需要独立的测试团队？
• 测试任务整合到团队项目中
• 测试开发比例：看具体情况而定

迁移传统过程

• 度量标准
• 与度量无关的事情
• 沟通度量
• 度量=》 something happened naturally
• CMMI VS Agile

敏捷测试象限

• 单元测试
  
  • 单元测试目的：单元测试的目的是通过测试帮助程序员理解代码需要什么同时提供正确的设计思路。
    实际上是设计可测试代码的过程。
  • 效率更高，通过单元测试发现问题，通过单元测试模拟问题，修复Bug
  • 让测试人员编写代码可能是个误区
• 管理技术债务
• 上下文环境中的测试（context-driven testing）
• 支持团队的面向技术测试

和需求的斗争

• 故事只是业务专家和开发团队交流的起点
• 用户故事+实例/自我测试+交流=需求
• 多个迭代完善需求
• 提问-测试应该是一个非常善于提问的人
  
  • 解决什么问题
  • 这个问题是什么
  • 带来什么价值
  • 最终用户是谁
  • 用户得到什么好处
  • 使用该功能之前和之后用户会做什么
  • 如何判断故事做完了
  • 最坏的结果是什么？
• 使用示例
• 涟漪效应- 看全局，定测试点，看哪些影响的系统
• FITNESS使用
• 测试降低风险
  
  • 什么样的数据会保存
  • 最坏的情况是什么
  • 很多严重的问题，通常在探索性测试中发现
• 可测性和自动化
  
  • 自动化测试策略制定
  • 工具：easyb,jbehave,cucumber,fitness,crosscheck，watir

面向业务的测试工具包

• 面向业务测试的工具策略
• 激发示例和需求的工具
  
  • 核对表
  • 思维导图
  • 电子表单
  • 模型
  • 流程图
  • 基于软件的工具？？
• 基于示例的自动化测试工具
  
  • 单元测试
  • BDD： easyb,JBehave
  • Fit/Fitness
  • GUI测试工具
• 编写测试的策略
  
  • 增量构建测试
  • 确保测试通过
  • 使用合适的测试模式？what and how?
  • 构建/操作/检查
  • 基于时间的,活动和事件模式
  • 关键字和数据驱动

探索性测试

探索性测试可能是敏捷测试最重要的方法了，那么他是什么呢？可能大家实际做的时候不这么叫他，但是你可能已经用他了。他就在那里。

探索性测试并不是通过详尽的测试来评估测试，而是通过实际的操作来判断是否完成的用户故事
真的满足需求，有没有更好的实现方法。这对于测试人员来说，需要测试人员更加了解被测系统。从后端到前端，从不同的各个子系统，
从可用性，交互的角度看。他给测试提供了一个新的维度，一个更全面的维度。但他很难真的说成是什么。