前两天听了公司一个关于敏捷开发的培训，就在想是不是也有敏捷测试。尽管一个同事说根本没有敏捷测试这个概念，但我仍不死心。Google了一下，这方面的文章确实有限，不过有就是对自己想法的一个最好肯定。
在我的理解对应敏捷开发的管理就是敏捷管理，同样对应敏捷开发的测试即是敏捷测试。只是敏捷管理和敏捷测试同样可以应用到非敏捷开发的项目中去。同样敏捷管理和敏捷测试在敏捷开发中将会得到最大的体现，但能不能管理好和测试好就看你做的是不是真正的敏捷管理和敏捷测试，看你是不是真正的将敏捷的思想融入到管理与测试中去了。
敏捷开发强调的是敏捷设计，设计的灵活性、可扩展性和易维护性是敏捷设计的目标。而之所以要有这样的目标就是为了适应多变化的需求，而敏捷开发中高度的迭代正是及早发现问题，及时修正并完善需求的有效方法。
那么敏捷测试的核心是什么呢，就是在设计阶段之前充分学习该项目的行业知识，从最终用户角度和实际出发充分的挖掘需求。在设计阶段要完成对敏捷设计的灵活性、可扩展性和易维护性的检查，这个工作最好由公司内部的其他结构师来完成，开发人员和测试人员列席并给出意见。在敏捷开发的高度迭代过程中，测试人员首先要从整个项目全局考虑，及早发现需要更改设计的问题，但时间上不能花太久，其实这个测试更多的是去看、去思考，而能不能发现问题就要看你对现有需求吃的是不是透彻，对整个项目是否有一个全局的把握，是否从最终用户角度去考虑问题，是否以实现客户的商业价值为目标;然后在最短时间内完成所有功能和业务逻辑的测试，最好是每人分配不同的功能和业务逻辑进行测试，这样就可以在最短时间内及时将优先级较高的bug及时反馈给开发人员;最后在开发人员忙于修改那些优先级较高，难度较大比较耗时的bug时测试人员可以有充分的时间来对这一迭代进行较细致的测试，发现功能和业务逻辑中不易察觉的问题，次要功能问题、验证、界面等等问题。
关于敏捷测试的测试用例问题。很多人觉得测试用例没有用，其实那是因为测试用例只是又书写了一遍需求，这样的用例当然没有用。对于敏捷测试，在写测试用例时我们必须要花很短的时间写出高质量的测试用例。在我认为敏捷的测试用例就是以简洁的语言写出所有测试点，甚至可以不要期望结果，因为很多期望结果要么能在需求中找到，要么对于一个有一年以上测试经验的测试人员来说已成竹在胸。如果为了严谨，可简单写明结果，如果没时间可在后期敏捷测试过程中工作量不饱满时补上也未尝不可。同时敏捷测试用例必须在敏捷测试过程中不断得到更新，在我们测试过程中、思考过程中完成测试用例的更新，因为敏捷测试用例简洁的特点不会花太多时间。
当然对于测试人员与开发人员的沟通问题也非常重要，如果测试人员觉得自己提出的bug别人可能会有疑义或者别人不仔细研读并不能直观地理解其意，那么最好在这个bug后面写明自己的想法，开发人员在处理测试人员提交的bug时同样如此，对于有不同看法的bug一定要加上注释说明原委。在此基础上再进行沟通，我想剩下的问题不会太多，不会耽误双方太多时间，这样得沟通更易于让人接受、效率更高。测试人员之间的沟通与交流同样重要，每个测试人员对需求可能都有不同的理解，沟通可以使他们对需求的理解更趋于一直，更高效的发现问题。测试人员间相互查看对方提交的bug，同样是一种更有效的沟通和交流方式，可以发现别人看问题的不同角度，从而取长补短共同进步。总之在不影响别人工作的情况下尽可能与其他人做充分的沟通也是敏捷测试中的重要部分。
敏捷测试的管理同样是一个非常重要的部分，有时间整理一下再做补充。
对于敏捷测试必须有一个非常良好的环境，这个环境能够让测试人员有非常活跃的头脑，良好的心态，能够非常自由的去思考，愿意去思考。其实很简单就是如果能让每个测试人员下班的时候都是开开心心的回家，那么这个环境就是最好的环境。
关于敏捷测试的一个不成熟的定义：一种面临迅速变化的需求和频繁迭代，迅速制定出与当前迭代高度适应的测试策略，快速做好测试准备并执行测试，尽早的发现优先级较高的bug、在有限的时间内完成覆盖率较高、测试较充分的测试。
