以下是小编为大家准备的敏捷测试实践（共含5篇），欢迎大家前来参阅。同时，但愿您也能像本文投稿人“冰冰草莓酸”一样，积极向本站投稿分享好文章。
1、什么是敏捷模式：
敏捷模式是一种应对快速变化的需求的一种软件开发模式，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用，敏捷的模式并不是一个方法论，而是一个世界观。
甚至敏捷不是一个方法论，顶多也是一种世界观。当在做一件事而又不确定哪种方法正确时，就可以参考一下原则，看看是否与原则相违背；
2、敏捷模式的实现方法
采用敏捷的开发模式不是说前期的需求什么的都不需要讨论，系统设计不需要了。在项目的前期，PD需要完成PRD，召开PRD评审会议，或者出原型之类的，务必使项目的成员都了解项目的需求。
对于没有使用过敏捷模式的团队，还需要召开Scrum计划会议，介绍项目的整体管理（流程，方法，工具和团队组建）等。
另外在流程开始之前，我们需要介绍一个名词，UserStory。用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：角色——谁要使用这个功能；活动——需要完成什么样的功能；商业价值——为什么需要这个功能，这个功能带来什么样的价值。指定UserStory并没有统一的标准，项目组N个人可能有N种粒度的UserStory；从测试的角度来讲，我们需要保证没有遗漏。
迭代计划：迭代的划分
设定UserStroy
任务的分解
工作量的评估和认领
对整个迭代的整体计划进行确认；
任务执行：开发和测试按照迭代计划执行
每日站立会议：沟通已经完成的进度，当前计划和当前问题
提前进行部分功能交付测试
全部功能测试
团队回顾：评审会议
产品交付验收
3、敏捷模式和非敏捷模式的区别：
使用敏捷的模式开发项目，更多的是要求项目成员之间能够彼此信任，互相协作，同心协作，相互沟通，
使用需要项目组的成员发挥自己的主观能动性。
对比瀑布模型：
个体和交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
对比迭代模型：
迭代模型是以模块为最小划分单位，每个迭代采用的可能是小规模的瀑布模型；而敏捷模式，是以一段时间为止，我们尽可能多的实现UserStory，；
4、敏捷的适用范围
敏捷的是在充分了解项目的基础上进行的一种类似于手工作坊的开发模式。因此在所有的项目中都可以使用敏捷的思想，但是如果完全使用敏捷的开发模式，个人觉得以下类型的项目比较适用：
对实践型需求变更较频繁的项目比较适用：对于那些需要严格按照PRD进行开发的项目不合适，比如微软需要开发一个win9的系统是不可能采用这种敏捷模式的。
对逻辑简单的项目比较适用：对项目逻辑复杂，关键性高，可靠性安全性等方面有较高的要求的项目需要在开发的每个过程中，都需要多方认证，适用敏捷模式不合适。比如需要淘宝的登陆系统，就不可能使用敏捷的模式。
对团队成员少而精的项目比较适用：如果一个项目中，人数越多，面对面的沟通的代价就呈几何级往上增加。
对模块独立的项目比较适用：如果项目中，模块和模块之间的耦合度较高，相互之间依赖严重，整个项目只有很少的UserStory，使用敏捷模式会造成项目敏而不捷。
5、敏捷实践的经验和教训
避免无计划性：在以往的开发模式中，测试计划是绝对时间，而敏捷模式中，测试计划是相对时间。以往的开发模式在某段时间中，任务比较明确，而在敏捷模式中，容易造成无计划没目标。对于这种情况，除了有任务计划之外，能够自己指定一份计划，给任务计划确定具体的完成时间点。
避免无纪律性：敏捷的模式是支持需求变更的，但是我们不能够无谓的变更。所有的开发和测试同学都不希望自己的项目中存在不确定因素，但是使用敏捷模式，我们需要接受这种变更；
任务划分思考不足：从下面的图中（最开始并行上升段）我们可以看到，预计的总的开发时间（蓝色的线）是上升的，表示项目的考虑不够充分！在实际开发的过程中发现了不足之处，然后进行改进，导致整个工作量的增加，例如我们项目使用的是WEBX3，结果hecla不支持webx3，目前仅支持从webx2升级到webx3的兼容模式。
任务填写不准确：不是项目组中的每个同学都能坚持每天都在XPLANNER中填写时间的，如果时间填写不准确，则无法准确表达当前的项目情况（资源投入情况，项目质量等）。
文 / 朱少民
有一次，当开发人员完成当前Sprint 任务的代码之后，测试人员、开发人员和产品经理一起来浏览产品、从头到尾走一遍，产品经理发现了问题，认为需要对功能进行比较大的修改，这时开发人员估计需要两天时间才能完成代码，但测试人员反对这样做，我们本来只有5天测试时间，加上这次新做的功能比较多、开发代码质量不高，验收测试已经很紧张。如果再延迟两天，测试没法完成。产品经理说，你们不是在用敏捷测试方法，应该测得很快，三天应该能完成测试工作啊！
什么是敏捷测试呢？敏捷测试当然不能简单地理解为测得更快，绝对不是比以前用更少时间进行测试，也不是将测试的范围缩小了或将质量降低来减少测试任务。也有人说，只有敏捷开发，没有敏捷测试。下面我们将要讨论一下：
究竟什么是敏捷测试？
敏捷测试有哪些流程改进？
测试人员如何面对敏捷测试的挑战？
在敏捷测试中如何制定相应的自动化测试策略？
什么是敏捷测试
假如将过去传统的测试流程和方法硬塞入敏捷开发流程中，测试工作可能会事倍功半，测试人员可能会天天加班，而不能发挥应有的作用。敏捷测试应该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈，如图1所示。
图1 敏捷测试定义的形象描述
敏捷测试流程的优化
在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用四周时间，也就是每个月发布一个新版本。开发周期短，功能不断累加，给软件测试带来很大的挑战，软件测试流程要做相应的调整。例如，我们原有的测试规范明确规定，首先要建立项目的主测试计划书，然后再建立每个功能任务的测试计划书，测试计划书有严格的模板，而且需要和产品经理、开发人员讨论，并和测试团队其他人员（包括测试经理）讨论，最终得到大家的认可和签字才能通过，仅测试计划经过“起草、评审和签发”一个完整的周期就需要一个月。在敏捷方法中，不再要求写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来就可以了。
在原有测试规范中，要求先用Excel写出测试用例，然后进行讨论、评审，评审通过以后再导入测试用例库（在线管理系统）中。在敏捷测试中，可能不需要测试用例，而是针对Use Case或User Story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发原有功能的自动化测试脚本，为回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合这些考虑，敏捷测试的流程简单有效，如图2所示。
图2 敏捷测试流程简要图
在敏捷测试流程中，如前所述，测试是一个持续的质量反馈过程，测试中发现的问题要及时反馈给产品经理和开发人员，而且某些关键方面也要得到我们足够的关注，主要有：
测试人员不仅要全程参与需求、产品功能设计等讨论，而且要面对面地、充分地讨论（包括带语言、视频的即时通讯），仅仅通过邮件是不够的。
参与代码复审（Code Review），并适当辅助开发人员进行单元测试。
在流程中增加一个环节“产品走查（Product Walk-through）”——测试人员和产品经理、开发人员等在一起，从头到尾将新功能看一遍，可直观、快速地发现问题。
新功能的测试和回归测试策略
测试任务简单地可分为新功能测试和回归测试。在敏捷方法中，针对这两部分的测试建立相应的策略，以提高测试的效率，最大限度地降低质量风险。新功能测试的策略主要有：
不需要测试用例，直接基于用例和对需求的理解来完成新功能的验证。即使要写测试用例，只要保证各个功能点被覆盖，不要过于详细（大颗粒度）。
持续地进行验证，一旦某块新代码完成（Code Drop），就开始验证，而不是等到所有代码完成后才开始测试。这也包括参与到单元测试和集成测试中。
实施端到端（End-to-End）的测试，确保完整的业务流程的实现，同时，也容易发现业务逻辑不够清晰、不够合理等各方面的问题。
阅读代码来发现问题，可以和开发人员工作保持同步，消除测试周期的压力。
基于经验，可以实施更多的探索性测试、组合交互性（Interoperation）测试和用户场景(User Scenario)测试，更有效地发现埋藏较深的缺陷。
回归测试是敏捷测试中需要面对的难点。每次迭代都会增加新的功能，一个产品可能会经过十几次、甚至几十次迭代，回归测试范围在不断增大，而每次迭代周期没变，可能还是一个月。这样验收测试的时间非常有限，所以回归测试很大程度上依赖于自动化测试，因为很难将回归测试控制在非常有限的范围内。当然，还是有些办法可以帮助我们减少回归测试的范围，例如：
通过执行Code Diff 来了解代码变动的所有地方，再做代码关联分析，就可以明确知道要进行哪些地方的回归测试，回归测试范围会大大缩小，
基于风险和操作面分析来减少回归测试的范围，例如回归测试只是保证主要功能点没有问题，而忽视一些细节的问题。
持续测试的过程，只要有时间，就进行测试，包括开发人员、产品设计人员都参与到日常的试用和测试中来。
自动化测试策略
由于开发周期短，需求、设计等方面沟通也需要花费很多时间，没有足够时间开发自动化测试脚本，至少对新功能的测试很难实现自动化测试。这时候，就需要正确的策略来提高自动化测试的效益，如图3所示，并说明如下。
图3 自动化测试的策略
构建一个灵活的、开放的自动化测试框架，如基于关键字驱动的自动化框架，使测试脚本的开发简单易行，脚本维护也方便。
针对稳定的产品特性开发自动化测试脚本，也就是针对前期完成的已有功能开发自动化测试的脚本，而大部分新功能测试采用手工测试
集中精力在单元层次上实现自动化测试，主要由开发人员实施，测试人员提供单元测试框架，并辅助完成一些所需的基础工作。
在产品设计、编程时就很好地考虑了自动化测试的需求，使全面的、自动化的底层测试、接口测试成为可能，尽量避免用户界面（UI）的自动化测试。
良好的IT基础设施，包括自动化构建软件包、自动化版本验证（BVT）、自动化部署、覆盖率自动产生等。
敏捷测试工具
自动化测试依赖于测试工具，所幸的是，目前已有很多敏捷测试工具。由于篇幅所限，这里只是简单地列出一些常用的敏捷测试工具，不再深入讨论了。
单元测试工具：TestNG、xUnit家族（如JUnit、NUnit）、JMock、BizMock等。
功能测试自动化：ThoughtWorks Twist。
Web功能测试（frontend）：Selenium IDE/RC、WatiR、WatiN。
Web service测试工具（backend）：soapUI。
性能测试：JMeter+BadBoy。
验收测试框架：Fitnesse、Tellurium。
敏捷测试过程管理工具：微软的Visual Studio ，包括TFS 2010、Scrum模板（MS VS Scrum 1.0）、Test Manager 2010、Coded UI Test等。
业务智能（BI）应用的测试框架：Oraylis BI.Quality （+ NUnit）。
其他一些协作工具等，如TestLink、BugZilla、BugFree、Wiki等。
测试人员在敏捷方法中的价值
在敏捷方法中，开发人员的主导作用更明显，系统设计、编程实现、单元测试、重构等看似关键的一些任务都落在开发人员身上，测试人员容易被边缘化。那么，在敏捷方法中，测试人员的价值又如何体现呢？
在需求和功能设计讨论上，测试人员可以站在客户角度来阐述自己的观点，扮演“用户代表”角色，强调用户体验，真正体现测试人员和开发人员的互补作用。
测试人员不仅扮演“用户代表”角色，而且通过需求讨论、代码复审等各种活动及时地提供质量反馈，包括代码质量、接口一致性等，保证在产品构造的整个过程中质量受到足够的关注，以提高质量改进的持续性和可视性。
测试人员应积极参与单元测试，即使不参加单元测试，也应督促开发人员进行单元测试，确保单元测试达到80% 以上覆盖率，确保开发出具有良好可测试性的代码。
在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统（模块或组件），集成测试和端到端（End-to-End）测试显得更为重要，测试人员在这些测试上能发挥更大的作用。
产品发布前，验收测试和回归测试依然不可缺少，这更是测试人员的用武之地。
一个迭代周期结束后，对缺陷根本原因进行分析、总结规律，帮助开发人员建立良好的习惯，预防缺陷，从根本上提高产品质量。
理想情况下，测试人员掌握设计模式、具有很好的编程能力，可以和开发人员进行角色互换，如在当前版本开发中担任测试人员角色，在下一个版本开发中则担任开发人员角色。这样双方对不同角色的工作有着更深刻的认识，消除沟通的障碍，开发的效率和质量会有进一步的提高。
总结
根据上面的讨论和我们的实践，最后针对敏捷测试进行一个简单的总结，就是：
敏捷测试就是持续测试、持续反馈，扮演“用户代表”角色，确保产品满足客户的需求。
敏捷功能测试 = 新特性的手工测试（Use Case验证和探索性测试） + 原有功能的自动化测试 （回归测试）。
敏捷测试人员和开发人员的区别越来越小，理想情况下，敏捷方法中，测试人员和开发人员在不同的迭代周期可以互换。
敏捷测试流程依据不同的团队特点、不同产品的特点而不同，因地制宜，适合才是最好。
作者朱少民，网迅（中国）软件有限公司资深QA总监。中国科技大学软件学院教学指导委员会委员，中国软件测试认证委员会（CSTQB）资深专家。在软件工程 领域颇有建树，先后获得多项科技进步奖、出版十多部著作和高校精品教材，如《全程软件测试》、《软件测试方法和技术》等。
本文选自《程序员》杂志10期，更多精彩内容敬请关注10期杂志
敏捷测试有什么前途
问题描述：
我在一家外包公司做敏捷测试，已经两个月了，感觉除了对业务的积累外，其他再无积累，不知道以后该怎么转型。有前辈愿意指点一下小弟吗?
精彩回答：
王晓明：
敏捷测试人员的职业发展空间，个人技能和经验的提升都远远多于传统测试。成为一名优秀的敏捷测试工程师的要求也非常多，我罗列一下技能云，和潜在的发展方向，仅供参考，
● 领域知识
● 分析方法
● 解决问题能力(有点宽泛啊)
● 自动化测试设计和编写能力
● 持续集成，持续交付的知识
● 与用户，客户沟通技巧
● 与团队沟通技巧
● 项目管理能力
● 质量管理能力
潜在方向：
● 测试专家
● 质量保证专家
● 咨询师，教练
● 项目经理
本文主要从提升项目质量、促进知识传递及减少项目风险等角度出发，讲述作者所在团队在结对编程实践中的一些经历，以及如何避免或减少其所带来的负面影响，
你了解结对编程吗？你尝试过结对编程实践吗？也许你还未曾尝试甚至还不曾了解，那么我们一起来学习和了解敏捷结对编程实践，相信对敏捷感兴趣的你会有收获。
什么是结对编程
结对编程（Pair Programming）是一种敏捷软件开发实践，指两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘和鼠标一起工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）， 两个程序员定期互换角色。他们在一起完成需求分析、系统设计、编码、单元测试、整合测试（Integration Test）、写文档等工作。基本上所有的开发环节都一起肩并肩地、平等地、互补地进行工作（如图1所示）。
图1 共用一台电脑进行结对编程
上面是极限编程（eXtreme Programming，XP）对结对编程的描述，它有如下主要的优点：
有利于提升项目质量，减少Bug；
有利于知识传递，降低学习成本；
多人熟悉同一段代码，减少项目风险；
与别人一起工作会增加责任和纪律性等。
尽管结对编程有诸多诱人的优点，但实行结对编程实践的却为数不多，其主要原因可能有：
结对编程需要投入更多的资源；
结对双方需同时注意力集中，否则效率更低；
结对人员能力要求相适，否则起不到观察者的作用，甚至产生依赖；
不成功的配对，经常引发争吵，产生内耗，导致团队不和谐等。
结对编程是颇具争议的敏捷实践之一，除上述一些优缺点外，可能大家还有更多不同的看法，但分析利弊不是本文所要讨论的重点。
实践经验
就我所在的项目团队而言，6人左右的开发团队需要支持多个中小型独立产品的需求开发，在繁重的业务压力下，用户价值的快速交付是首要的，所以想尝试共用一台电脑进行结对开发的实践只能是一种奢望。让团队开发人员尽可能熟悉相互间的产品代码，提升项目开发效率以及保证良好的项目质量，是我们在项目开发过程中需要重点解决的问题。
我们试图通过集体Code Review和设计交流分享等活动，来提升代码质量以及相互间业务代码的熟悉度，但一直收效甚微。问题主要在于这种集中式活动时间较难安排，人多交流效果不佳，性价比不高。后来，得益于公司的导师机制，在一对新人和导师身上，找到了敏捷结对的原型。由于他们的紧密合作，遇到问题及时沟通，新人在项目进度和质量都有不错表现，很好地融入了团队，
在后续的项目过程中，我们不断地尝试和优化这种结对形式，逐渐形成相对固定的工作方法。
与XP结对编程相比，敏捷结对编程最为显著的差异是结对进行需求分析、系统设计和问题讨论，但分别编码实现，通过过程中频繁的Review来实现结对的效果。开发人员两两结对，共同认领开发任务，一起对所承担的开发任务负责。在需求理解、设计阶段双方一起设计和讨论，然后分工各自编码实现，并通过Code Review以确保实现与设计一致。对结对过程中发现的问题，随时沟通和讨论。由于产品业务逻辑相对不是特别复杂，所以通过这种小范围、高效的沟通，可以解决项目中的绝大部分问题，实现更高的开发效率并确保代码质量。目前，在开发流程中的主要结对活动如图2所示。
图2 敏捷结对的主要活动
结对活动（如图3所示）给我们带来了哪些好处？
提升项目质量。结对开发人员在需求理解、设计思路上进行了充分的沟通和讨论，能尽早地发现和解决问题，避免前期因需求理解偏差、设计缺陷问题造成返工。
知识传递。对于新员工或经验略逊的开发人员，通过经常性的沟通和讨论，能迅速地进入角色和积累经验，发挥了传帮带的作用。
backup，规避项目风险。结对人员之间互为backup，有利于团队成员之间熟悉业务代码，若有人员异动时有利于项目风险控制。
图3 结对人员充分讨论设计细节及问题
无论新老结对还是强弱结对，都要尽力避免一方对另一方产生依赖，要给新人足够的成长和锻炼空间，让其独立思考和解决问题，并允许在可控范围内尝试失败，以获取宝贵经验得到成长。否则，团队只会多一个执行者，结对难以达到预想的效果。同时，一定程度的独立活动，可以让大家保留自己的工作习惯，而且形式更为自由和灵活。当然，大家可能会有疑问，如何保证结对人选中资深工程师工作的正确性，因为新人和弱者很有可能无法提出想要的Review帮助。这个问题在我们的结对中不可避免，有选择地邀请其他资深专家Review，也许会是个不错的解决方案，特别是对于一些重要的复杂业务逻辑。
参加结对的工程师应具备独立思考和解决问题的能力，并且具备较好的团队协作意识。否则，不仅不能有好的结对效果，反而会带来一些新问题。此外，结对也不仅限在研发工程师之间，研发和测试工程师之间或同产品经理之间的结对（如图4所示），同样可以带来不错的效果。
图4 研发、前端工程师测试之间结对解决问题
引入敏捷实践，贵在充分理解、结合实际，能扬长避短，且是一个适应、发展的过程，而按部就班绝对不是个好主意。有选择地结对对我们来说也许是上策，在结对的人选、场合、结对的环节等方面进行选择性的实施。
作者金建法，阿里巴巴B2B公司技术主管，具有多年互联网开发和项目管理经验，对J2EE和敏捷项目管理有着浓厚兴趣。
【从这篇文章开始，我打算在本专栏中记录本人在组织中推进敏捷测试的工作过程，这篇文章描述的是从5月到8月共3个月内的主要工作，在两个月的时间内，我们初步决定了发展方向，在敏捷测试的氛围建设方面都有了一些进展。2个月中主要的工作是：团队改造，工具体系搭建，建立了初步的开发和测试的尊重和良性互动，开始在少数项目中使用自动化测试建立更好的反馈机制和提升效率】
2011 年4月，我离开了原来的团队，加入了一家200人左右的互联网创业公司（以下简称H公司）并担任该公司的Engineering VP职务。我负责的团队包括一个产品开发团队，测试团队和其他两个团队。离开一个成熟的敏捷环境，进入一个新环境，我期望能够使用敏捷方法让这个新公司的开发和测试部门能够有更好的生产率和更好的工程师驱动的文化。从6月份至今，我已经在组织内推进了一些与敏捷相关的行动，从结果上看，敏捷的意识和氛围的确向前推进了一些。当然，在我看来，创造一个更接近敏捷的环境是手段而非目的，因此，这一系列的笔记仅用来尽可能忠实的记录我在这个组织中推进敏捷测试的方式，以及这些推动带来的改善。
H 公司是一个以social game开发和发布为主要业务的公司，在我刚加入的时候，H公司的测试团队有15人，几乎全部成员都没有什么技术背景，采用的测试方式是典型的手工测试。团队使用Testlink工具管理用例和测试执行，使用Bugzilla系统进行缺陷跟踪，自行开发了提测系统用于管理测试提交。测试人员分布在各项目团队中，每个项目有2-4名测试工程师，测试工程师的主要工作方式是被动接受测试任务，按照开发工程师指定的测试范围进行手工验证。显然，这是一个国内企业典型的传统测试团队，测试团队成员充当“发现问题的最后一个环节”，以黑盒和手工测试的方法对应用进行验证。
Socail game这个是一个竞争非常激烈的行业，对social game来说，快速更新和快速发布往往是一款游戏能否成功的关键之一。因此，对H公司来说，快速发布的能力非常关键。通常，开发工程师可以在一周内完成 3-4个新功能提交，但由于测试工程师需要在多个平台和多个浏览器上对应用进行测试，结果测试往往成为产品发布的瓶颈。从开发工程师和产品的角度来看，测试时间太长；而如果为了缩短测试时间而仅将测试范围定义在新功能上，测试中又会遗漏不少问题，导致结果不理想。在这种状况下，测试工程师越来越忙，却完全不能真正在提升产品质量方面发挥作用。
显然，H公司的测试团队采用的传统测试流程和方法在这类要求“快速”的企业中很难适应，除非对测试团队的行事方式与测试文化进行一个彻底的改造，测试团队很难在组织中发挥重要的作用。
团队在敏捷中的重要性不言而喻。团队是由个人组成的一个集体，在我看来，决定团队的水准的，自然是团队中的每个个体，如果一个团队中的成员根本就不具备帮助达到这个团队目标的能力，再有能力的领导，再好的愿景也是白扯。因此，首先需要的是从人入手改造这个团队。这个团队中的成员几乎都没有很好的开发和编码背景，要求他们从开发的角度理解测试、理解生产率和推进自动化是不可能的事情。对他们来说，对自动化的理解很可能就是找个工具录制一下，形成脚本，然后简单的维护一下脚本。而我期望推进的是，建立一支真正能够真正与开发形成良性交互，能够帮助推动整个组织的生产率和产品质量的队伍。考虑到整个公司的现状，大规模的替换测试团队的成员是不现实的，因此，在测试团队之外，我们新成立了一个Tools/Automation的组，这个组的目标是推进整个组织的自动化，从生产率上帮助建立自动化框架（不仅仅是测试自动化，而是整个组织的自动化和生产率）。这个组的每个成员都由我自己担纲招聘，虽然到目前为止这个团队只有四个人，但由于每个人的编码和测试经验都比较不错，更重要的是，他们都是爱折腾，对结果负责，愿意推动事情发生的人，因此，到目前为止他们在推动敏捷测试环境方面发挥了主要的作用。
除了建立新的团队外，提高原有团队的招聘标准是另一个手段。虽然各个项目组在新功能更新频繁的情况下，不断的要求增加新的手工测试工程师，但在我的坚持下， “新进入的测试工程师必须要求具有一定的编码技能和知识背景”这一条要求还是能够得到满足。当然，项目组缺人的问题是必须要解决的，因此我主要依靠在项目中可以明确看到结果的逐步的自动化测试推进让项目组意识到依靠自动化测试解决他们的问题比依靠手工测试有效得多，
此外，在整个团队中不断要求和灌输“测试价值”的理念，使得开发和测试工程师都能认识到单纯的以“发现缺陷”为目标的测试文化是很难在现有环境中产生价值的。
这里所说的自动化，并非仅仅意味着“自动化测试”。诚然，自动化测试是敏捷测试的基础，但采用自动化技术让产品发布自动化、让不同层次的测试都存在执行的基础，这样才可以将开发和测试工程师纳入到敏捷测试的同一阵营中来。
为项目建立自动化的构建环境和持续集成环境
每个项目最少需要有自动化的构建环境和持续集成环境。哪怕持续集成中仅包含一个测试用例，持续集成也至少可以让整个开发组织能够建立基于反馈（持续集成结果）的开发方式。而自动化的构建环境则允许开发和测试之间的协同工作变得简单，且减少了构建过程中出错的可能。能够用于建立自动化的构建环境和持续集成环境的工具非常多，这里就不再赘述具体过程。
建立初步的代码质量体系
高 质量的代码是高质量软件的基础。除了对产品的测试外，从源头开始控制代码的质量对促进和提高产品质量也非常关键。Code Review是极好的进行代码质量控制的手段，基于H公司的svn代码库，我们通过钩子，加上开源的一些Code Review Dashboard工具建立了一套强制的Code Review流程，要求所有代码必须经过Code Review后才能被check in到代码库。另外，Code Review系统中集成了静态代码检查工具，Reviewer在评审代码的时候可以直接看到提交代码的静态检查结果报告。
自动化测试
敏 捷测试中，自动化测试是必不可少的重要环节。但是，在组织中推进自动化测试并不是一件轻松的事情。首先，如果组织的测试目标已经被固定成了“尽可能发现最多的缺陷”，如果开发工程师、甚至测试工程师自己已经习惯了把发现缺陷和工作时间当成自己唯一的评价标准，在这种情况下推动自动化测试，结果不言而喻。
组织首先要有自己明确的自动化测试可达成的目标。在我的理解中，自动化测试的最大贡献在于两个：1，让全体工程师（测试和开发）都可以成为测试的执行者和设计者，让验证可以在尽可能小的周期内发生（快速反馈）；2，自动化测试不以流程为中心，可以持续演化并适应快速的需要。对H公司来说，显然，通过自动化测试可以达成的，与团队期望最契合的目标应该是“通过自动化测试尽可能在短的测试周期内达到更高的覆盖率”。因此，在我们的自动化测试推进中，该目标成为了自动化测试需要达成的最首要的目标。
对于任何应用来说，从技术角度来看，最好的自动化测试都应该是在产品设计时引入可测试性，这样可以在不同层次上对应用进行验证。但如果对一个已有产品已经比较固定，且很难对其进行大规模重构的组织来说，对这些已经固定的产品进行重构以便于自动化测试的开展显然是不现实的。在自动化推进时，我们并没有把自动化测试建立在革命，而是革新的基础上。虽然我本人是坚定的大规模UI自动化的反对者，但在对H公司的产品（游戏类应用）进行了详细了解，以及对开发过程进行了详细了解后，我还是不得不承认，在现阶段，使用主要基于UI的自动化测试是更适合H公司现状的方式。目前我们选用的自动化测试工具是Sikuli工具，基于该工具设计了一套适合H公司游戏产品的自动化测试框架，通过mock本地环境等手段，目前UI自动化测试的稳定性可以达到95%以上，对于游戏的测试是一个很好的提升手段。
以上就是我们在3个月内为敏捷测试推进工作进行的改进。不得不说，到目前为止，这才是在前进的道路上迈进了一小步。真正的组织级的敏捷需要持续建立更好的沟通、建立自承诺的团队，以及持续改进。不管怎样，在这3个月的时间内，我们通过这些工作，测试团队的氛围开始发生了变化，开发工程师开始愿意配合测试团队，为其提供更好的测试接口，所有的测试成员都开始意识到交付价值比交付bug重要…… 这是我们向敏捷推进的一小步，但相信是坚定的一步。
接下来的一段时间内，敏捷的核心价值观仍然是指导我们的法则，持改变的勇气，不断检讨，不断优化；保持简单，把资源投入到最值得提高的地方；建立更好的沟通方式，更好的信任与尊重，相信一段时间后，我们能看到接下来的仍然坚定的下一步。
★ 敏捷结对编程实践
★ 软件测试实践心得
★ 敏捷的反义词
★ 创造力测试
★ 测试邀请函
