迁移传统过程

之前一直写的都是敏捷测试要怎样做，没有提到要怎样做敏捷测试。目前大多数的团队还是采用传统的测试过程，这一点不可否认。有人坚持传统测试，有人提倡敏捷测试，书中的第五章提到了传统测试向敏捷测试的过度，这里就把它拿出来，和想转向敏捷测试的书友们交流一下体会。

---

度量的问题

“世界上有三种谎言：谎言，该死的谎言，还有统计数据”。可度量的目标是一件好事。既然是一件好事，又为什么说是谎言。举个栗子，单元测试的数量在增长，但是代码覆盖率从75%降低到50%，这不一定是表面看到的这样，也许是我们去掉了测试覆盖的无用代码。度量是必要的，但是独立看待度量是错误的。在传统的测试过程中，经常使用缺陷数量来度量测试团队是否做得好。那在敏捷测试中，首先要考虑所定义的度量代价是否是合理的，并且多使用小目标来作为自己的度量。比如：在产品发布的六个月内，新代码中的严重缺陷不能超过六个。

---

缺陷跟踪——用卡片还是DTS？？

我的观点是，都可以，只要适合你的团队。

因为使用DTS有很多好处：

1.方便：信息填写的过多，不太适合记录在卡片上；

2.知识库：以史为鉴，可以轻易的找到缺陷，而不是靠某个人的记忆力；

3.可跟踪性：它链接了缺陷和测试用例。

也有一些特点使得它阻碍了敏捷测试：

1.沟通工具：DTS的使用不会增加开发和测试人员之间的沟通

2.浪费时间和精力

3.敏捷和精简思想提供了一些实践和准则帮助我们减少对DTS的依赖，如果过程可靠，所有的成员致力于产品质量，缺陷可能很少很少并易于跟踪。

所以，总的来说，DTS还是有必要的，只是需要找到适合自己团队的工具，因为工具需要整个团队使用，选择时要考虑所有人的看法。

---

测试计划&测试策略

传统的阶段性软件模式强调测试计划的重要性，作为整个文档需求的组成部分。在敏捷项目中，团队不会依赖沉重的文档来通知大家该如何做，测试人员会和大家进行沟通，但并不意味着他不需要计划。在这里采用“策略”，关键词是“长期”，可以记录在静态文档中，而测试计划对每个项目都是唯一的。一份测试策略的主题主要包括：

      测试实践

     故事测试

     解决方案验证测试

     用户验收测试

     探索性测试

     负载和性能测试

     测试自动化

     测试结果

     缺陷工作过程

     测试工具

     测试环境

---

现有的过程和模型

质量模型有很多，书中主要提到了两个CMMI以及ITIL。这两个模型都可以很好的与敏捷开发共存。其实这里我没有太看懂，之后会再学习这两个模型究竟是什么东西。还请大家多多指教。

最后附书中图片一张，列出了从项目启动到发布整个周期的工作，将敏捷的思想贯穿在其中，我自己也会在我们的团队中尽力将其落实，推进团队的敏捷进程~~

“与现有质量过程和模型共存是你在转换到敏捷开发中遇到的最大的文化问题。所有这些改变都是艰难的，但只要团队参与进来，就没有什么困难不能克服。”