自动化测试与敏捷开发 让人激动得无以复加
周六参加了Baidu技术交流会，会上的两个主题《webautomationtest》和《TDD》都是当前非常感兴趣的话题，因为：目前采用敏捷的方式开发我们的自动化测试框架和脚本。
敏捷这种模式或多或少大家都有些了解，虽然挺久之前对此有所了解，但一直没有深入，只是草草看些书籍，了解些梗概，也还相当混淆。
但这次为了采用这种开发模式，和头认真的学习《敏捷软件开发原则、模式与实践》这本业界的经典书籍，也根据书中的模式进行结对编程，测试驱动开发等极限编程的典型实践进行演练，对于敏捷这种开发模式有了客观的了解，当然，还不深入。
看看振奋人心的敏捷宣言吧：
我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为：
个体与交互胜过过程和工具 可以工作的软件胜过面面俱到的文档 客户写作胜过合同谈判 响应变化胜过遵循计划
虽然右项也具有价值，但我们认为左项具有更大的价值。
2001年的宣言，发展至今，已经指导很多公司进行了相关的实践。当然，我们这里也没有机会在发布的软件产品中进行敏捷的尝试，在产品层面，我们的影响还不够，但，在我们自己的自动化测试框架和脚本开发中，已经开始遵循敏捷中的典型方法?极限编程来指导我们日常的开发工作了。
在日常的工作中应用敏捷，激动的让人无以复加。看看如下的一些敏捷原则，你是否感觉到同样的激动？
在团队内部，具有效果并且富有效率的传递信息的方法，是面对面的交谈：我们越来越多的交互方式使用文档，使用电话，却没有发现我们的座位其实只有几步之遥，相比于那些交流方式，我更喜欢面对面和我的团队伙伴进行交流，这样我可以通过他（她）们的语言之外的表情，动作，了解他们更多的需求，也能让我产出的方案更贴近他们的需求；
工作的软件是首要的进度度量标准：放弃那些所谓的MPP吧，思维导图吧，大家真正需要的是可以工作的软件。有多少项目的产生周期是和MPP中涉及的一致的？
好的架构、需求和设计出自于自组织的团队：相信你的团队伙伴，同时，让你的团队处在积极，乐观，进取的氛围下，大家彼此快乐的工作，自愿为团队奉献更多的应用和方法，而不是用所谓的高压去推进。
。。。。。。
当然，这些只是原则的一部分，其实我更激动的是一种心态上的契合。
我一直相信，流程和方法能够辅助项目的成功，但真正引导项目成功的决定因素，还是人。在敏捷这里，我找到了理论的依据：“过程和方法对于项目的结果只有次要的影响，首要的影响是人”；“人是获得项目成功的关键因素”；“项目的成功不是以稳定可靠的产品作为输出，还要有不断进步的工程师”。。。
当现代项目，不断要求人去差异化，让大家成为零件的时候，这样的一种方法，能够让我们自身认识到自己的价值，并且在项目的发展中完善自己，我认为非常重要。
有时候，扪心自问，我们是否真的随着产品的成熟而进步？历经了一两年甚至几年的测试工作，是否在技术，视野等方面有了显著的提升？客观的说，我曾经的一些同事，负责某个产品已经数年，却连产品基本的一些业界通用的方法都不了解，不能自己实现，这样的结果让我感到非常悲哀。或许，每个人都应该从内心明确的认识到，自我的发展也是项目的产出之一，的测试工程师同样能够提高效率，提高产出，制造更多的价值。
再看看这条：可以工作的软件胜过面面俱到的文档。公司在进行流程的梳理与制定，以往很多的文档缺失，现在在弥补一些以往的稳定缺失，当是否需要很多文档呢？
在敏捷里面给出了一些指导的意见：没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。然后，过多的文档比过少的文档更糟！编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，要花费更多的时间。如果文档和代码之间失去同步，那么文档会变成庞大的、复杂的谎言，会造成重大的误导。
在文档方面，我从来不是文档排斥者，我只是排斥过多的文档，你有没有发现你的团队用大量的时间做一些没有意义的文档？我有过这样的经历，在调查部门其它同事的工作，发现他们大量的时间用来做文档，真正的测试工作相比于文档反而少很多。这样的文档的受众有多少？不过是部门的寥寥几个人。。。
也许有人会认为，文档是知识传承的良好媒介，有了详细的文档可以抵御人的流失。我不得不说，太多的文档正是人的流失的原因之一。同时，还要指出：好的知识传承的媒介是人！一个系统，如果能够保持耐心的给予新人足够的指导，我相信他们对于系统的理解要远远超越于枯燥的文档，当然，如果你能把文档写得像老舍的小说那样精彩，我也会认同你写文档的方式。
还有是，对于很多功能，为什么非要采用文档的方式来保存细节？我一直不明白，为什么不直接去看代码？类似我们的产品，每个人都有权限看代码，可以还是很多人愿意电话去问研发怎么回事，怎么回事，我有的时候很不理解。代码是真实的文档，也一定比编写人员的描述更准确，更多的时候，我们应该查阅代码，相信代码，而不是别人的描述或者某些早已过时的文档。
其实模式没有好坏之分，还是要根据应用的场景来选择开发模式。到目前来说，我认为在我们的自动化测试框架和脚本开发工作中，敏捷的模式可能更适用。
比如我们可以无障碍的保持和客户的交流，甚至把客户作为我们开发团队的一员；
比如我们可以并不关注文档，而已可工作的代码作为交付；
比如我们可以测试驱动开发，让我们测试人员编写的代码同样经过测试，让代码健壮，而不是总是问一些，为什么代码会报错，难道是wait不够吗等等问题；
比如我们可以在功能实现后进行不断的重构，让我们的代码更清晰，结构更合理；
。。。。。
有太多的比如让我们选择敏捷作为我们的开发模式。
当然，正如前面所说，模式本无好坏，而是看场景。敏捷本身也有他自身的弊端，但至少当前，是满足我们的需求的，也激励我们更多的使用和尝试，现在还浅薄，希望伴随着使用，能够对这种开发模式有更深入的理解。
