敏捷测试理论以及实践（4）

敏捷测试理论以及实践（4）

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

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

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

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

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

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

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

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

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

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

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

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

　c）测试也需要跟测试人员之间进行沟通，来探索怎么能发现有质量的Bug，怎么能覆盖到很多的测试点，怎么解决自己没办法解决的问题，帮助他人也帮助自己。（每日立会是其中一个好办法）

　　d）测试还需要跟自己沟通，不断地经常反思自己的优点和缺点，反思团队的优点和缺点，反思公司的优点和缺点，大胆提出和实施改进意见，为以后更好地开展工作做准备。（反思会是一种办法）

　　沟通，只有沟通才能了解双方的想法，才能及时消除前进中的阻力和困难，让大家在同一方向上用同一个信念前进。

　　3、建立有效的监测机制：这里所谓的检测机制主要有两点，一个是对测试的监测，另外一个就是对产品的监测。对于测试的监测主要在于检查测试的覆盖面是否全面，发现的Bug与测试覆盖面的一些对比数据，这些有助于提高测试的覆盖面从而提高Bug发现率；而对于产品的监测就是主要有两点，一点就是做功能和修Bug的进度是否是可控的，可预判的；另一点就是发现Bug的情况，也就是产品的质量是怎样的，质量发展的趋势是怎样的。

　　我主要想补充的是这么三点，当然要是我想到其它的，我还是会修改这篇文章的。看过网上也有很多人来写关于敏捷测试的一些文章，很多都是国外英文解释的标准中文翻译，当然也有很多是自己的一些想法，所以远近高低各不同，不过既然敏捷只是一种思想，也就不会拘泥于何种实现方式，所以各人有不同想法都Ok的。其实说的再过一点，只要你自己认为你的方法是敏捷的，那你就可以认为是敏捷的，不用关心人家怎么想，人家的方法不一定适合你的，你只要有办法能在正确的时间交付正确的产品，那就Ok了。

　　所以我接下来就会按照我们公司的流程来实际介绍一下敏捷测试在我们公司的实现，中间可能会有一些地方为主流敏捷测试所不容的，但是我觉得他们比较符合我们公司的实际，如果大家有不同的意见或者更好的方法，我也会悉心接受。

　　（未完待续）