软件测试思考系列[1]：往持续交付的方向努力
测试应该朝什么方向努力，怎样做才能避免陷入泥潭？产品不稳定的原因，粗略看上去，似乎是因为测试时间不够，测试不充分导致的，但是深入进去探讨会发现没有那么简单。这一篇文章是探讨测试应该朝着什么目标去努力，而我在这半年的实践中选择的是持续交付的方向，下面介绍介绍持续交付。
首先，如果测试不能从产品周期的一开始参与进去，后期等产品快发布前再测试，会面临很大的问题。工作量大不谈，如果发现了BUG，开发的修复时间也不够了，更不要说可能产生严重的架构问题，或者功能和需求不符问题。
其次，现在很多软件公司所面临的问题，是“铁路警察，各管一段”的问题，推诿职责，测试并不是银弹，不能解决全部问题，所以很大程度上需要责任共担。但这个东西是说起来容易做起来难的一件事情，当一个问题，你无法快速定位导致它的真正原因的时候，无从谈起问责。想要做到快速定位，将定位问题原因的难度降低，一个很重要的原因是快速反馈，功能越早的被测试，问题越容易被发现，也越容易被修复。做到这一点，主要是靠持续集成，而持续集成是持续交付的主要组成部分，原来听的比较多的也是“持续交付”，而持续交付的提出，更多的是为了解决所谓的“后一公里”的问题，因为很多的BUG或者问题，需要延迟到用户真实的生产环境中去才能发现。很多做法，比如Alpha应用等等，都是往这个方面做得努力，是不但要尽早的得到产品，还要尽早的部署。
再三，上面一篇文章中提到的反馈影响图，也要求反馈的循环速度越快，换个意思表达，也是持续的得到反馈，而只有真正集成或者交付后，才能得到有用的反馈。持续交付的概念，我早是从InfoQ上的一篇演讲学习到的，在这之前其实我只了解过持续集成。这个演讲(包括视频和PPT)的题目是让持续交付成为可能，不仅探讨了概念，还通过真实案例分享，与听众一起回顾某产品团队如何从传统开发走向持续交付。讨论在产品交付中如何应用DevOps原则（协作、自动化、度量和信息共享），达到快速且可靠地发布高质量的软件，同时描述过程中遇到的难题及解决方案，并进一步探讨持续交付的意义。很幸运看到这个演讲，开启了我的持续交付实践之路，在这里要感谢作者，带给我很多灵感和指导方向。(当时立马将这个演讲分享给团队成员，附带一句：“看了这个视频并且理解了的家伙，不谢我没人性”)关于持续交付，还有一本不得不介绍的好书，《持续交付》，配置管理，部署流水线等十分有用的概念，都是从这本书获得的，强烈推荐。
持续交付是什么样的？
软件的发布过程必须是可重复、可信赖的
把几乎所有的环节都做成自动化
把所有的内容都纳入版本控制
让痛苦提前，并不断练习
内建质量
“完成”意味着“已发布”
所有人对交付负责
持续改进，需要耐心
持续集成借鉴了敏捷思想，打破了用户、开发和测试之间的隔阂，实现了团队的协作。而近出现的DevOps则借鉴了敏捷思想，将敏捷原则应用于运维领域，使交付团队与运维团队建立起更紧密的合作关系。所以这里如果只介绍持续交付，而不介绍敏捷思想过意不去了。 2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的《敏捷宣言》，传递给世界，宣告了敏捷开发运动的开始。
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划
也是说，尽管右项有其价值，我们更重视左项的价值。
