什么是敏捷测试?

我感觉无论我们的测试如何做，都有一种感觉，测试永远没有做好。覆盖不够，粒度不够，文档不全，流程不明等等。。。。。。我在想，既然这些很能做好，那么我们为什么不去承认做不好这些是正常的呢？只是个度的问题。
所以我想以后测试的方向应该向着简单化的方向发展。那意思是说，测试更要依赖能力全面的人来担当，而不是靠严格的流程去约束。 这同敏捷开发是一个道理----简化过程，注重效率和个人能力，更加强调短周期的工作成效。
这样做的好处是简化了测试流程，加快测试进度，避免很多写文档和数据统计等浪费时间的工作。缺点是增大了不可预知的风险。  试想，原先的测试流程是：尽量解读需求--写用例--评审用例--用例覆盖分析--执行用例--缺陷跟踪--测试报告---数据统计--测试总结。并且几乎每个阶段都帮随着一些文档的生成和修改。那么我们看我所设想的测试过程（前提是开发按要求提供）：启用需求管理工具和配置管理工具，每个项目中，测试人员主动到需求管理工具去解读需求，然后到配置管理工具中去拿测试代码和测试程序，然后就可以按自己的想法去测试（测试思路要做简单记录），然后借助一个即时沟通的工具进行缺陷跟踪和与开发的交流，然后简单汇报测试结果。
  我想后一种测试至少能把测试周期缩短2/3。但它更需要测试人员的能力。而对于企业来说，后一种方法显然更能节约成本，缩短开发周期，产品更早的上线。既然有利益，那么这就是房展的方向。
   所以，我觉得我们要放弃cmmi那一套用文档和会议来控制过程，选择用我们的思路来控制过程。不过与之带来的个人因素增加的不可预知的风险也会增多，所以说需要能做到基本不出错误的人才和能敏锐感觉风险的管理者。