上面已经谈到了准敏捷测试模式了，离咱们所说的敏捷测试已经无限接近了，但是要了解真正的敏捷测试，还是需要回到敏捷开发上来讲，前面一开始已经说过，敏捷测试严格上来说其实是属于敏捷开发的一部分，所以敏捷开发的价值观也会同样适用于敏捷测试，那么敏捷有哪些价值观呢？总共是五个，分别是简单、沟通、反馈、勇气、谦逊。

　　光看这五个词，我想大部分人可能会晕乎了，不知所云的，难道敏捷五个词能概括了？像电影里出现的武功秘籍一样，一招一个图，我们看了根本不知道是啥，人家一看能炼成神功了。

　　其实呢，这几个价值观并不是教你怎么去实现敏捷，而是教你用一种什么样的态度去对待开发：要时刻想着简单的方法去处理需要解决的问题，要经常与和开发/客户沟通，对于积极对待反馈，要有勇气去做决策，对团队各个成员都要尊重。这么几个价值观，对于你去初次理解敏捷而言，我相信几乎没有用处，甚至会让你觉得很迷茫，到底敏捷是啥，但是一旦当你已经真正理解了敏捷的时候，你会发现，诶，的确是这样子的，说得很好！（哲学上说，事物的发展总是需要经历否定之否定阶段，对知识的理解也是一样，一开始看一下概念觉得很简单，觉得自己已经理解了（肯定）；深入下去，发现问题越来越多，觉得自己没办法去理解（否定）；到后经过不断地思索与实践，终于彻底理解后，你会觉得一开始那些简单的概念很精辟，应该那么简单！（否定之否定=肯定））

　　不过相对于当初的先行者而言，我们又是幸运的，因为很多前辈已经帮我们理解了这些价值观，并且研究出了很多实现的方式， 但是我们也不能去奉行拿来主义，毕竟是人家想出来的，是基于人家的实际情况，对于我们的情况不一定会适合，好的办法是取其精华，去其糟粕，结合实际，加以改进。

　　接下来我开始讲什么是真正的敏捷测试模式和我们公司怎么结合它来取其精华，去其糟粕，结合实际，加以改进。

　　当然这个所谓的真正的敏捷测试模式也是业内主流的模式，我们公司的实际运用中还是有所区别的，下面都会提到。

　　跟前面讲到的准敏捷测试相比，真正的敏捷测试其实也只是加以改进和丰富，所以与客户的沟通、积极响应需求的变更、以及开发与测试的同步，这些都还是存在的，当然敏捷测试改进和增加了许多地方，主要有：

　　1、过程需要实现迭代：每个迭代周期需要完成一定量的功能，没有完成的功能不能Check In代码，这些功能需要经过严格测试，并且开发需要修复主要的严重Bug，这样子在后得到一个可以工作的并且相对稳定的Build，这个迭代周期算完了，然后开始下一个迭代周期。这样类似与我们修路一样，修路的话需要打好几层地基，每层地基打严实后，再铺上面一层，这样子即使上层破了，只要修一下上层好了，不会影响到下面层的质量，如果是下面那层没打严的话，一出问题每层都会损坏，要修的话，要全部扒掉这么多层地基才能修好。所以迭代对于测试的要求特别高了，因为只有把这个迭代的主要Bug找到并修好，下面的迭代周期才能不受影响，才能确保以后出现的问题不用“打到底层”才能被修好，“打到底层”意味着是人力，物力，时间以及重要的产品的质量！

　　下面是一个迭代的简单示意图，应该可以理解的，不多讲了。

　　2、测试不单单要和客户沟通，也要跟公司里的人经常进行沟通，因为一个公司的所有人其实都只有一个共同目标，是把公司发展好，这样子其他的比如自己的发展，待遇等等才有可能实现。那么体现在实际的工作中是：

　　a）测试需要完全理解需求讲的知识点，不懂或者有疑虑要及时跟设计沟通，这样子可以让你更好地理解需求，甚至帮助设计人员发现错误；

　　b）测试人员需要经常跟开发人员沟通，看看做的功能，修的Bug主要会影响哪些其他模块，主要出现问题的原因是什么，怎么弄可以快速度重复出Bug来，这样子帮助自己掌握测试的方向以及帮助开发快速修复Bug以及避免以后出现类似Bug。