每个团队、每个项目以及每个企业都会遇到独有的自动化挑战。每个企业都有自己的文化、历史、资源、业务压力、产品和经验。无论你所在团队处于何种情况，你都可以使用敏捷法则和价值来寻找解决方案。勇气、反馈、简化、交流、持续开发和快速响应这些概念不仅仅属于敏捷，他们是所有成功团队所应具备的特质。
保持测试设计简单、保持范围最小化，使用最简单的工具完成工作。
简单是敏捷的核心价值。上手的最好方式就是你所能想到的最简单的方式。它需要思考哪些东西并设法达成目标，保持简单，如果做出了错误的决定，那么在发现错误之前不会偏离轨道太远。
我们很容易陷入到任务中并从基础转向挑战当中。在做之前需要先衡量一下每个自动化任务的ROI。尝试困难的东西很有吸引力，因为可以解决那些难题。与敏捷开发项目中其他测试方面一样，跟进的唯一方法就是只做需要的东西。
使用你能找到的最简单的工具。如果大部分客户测试能在单元级别自动化，那就在该处进行。例如使用FitNesse编写测试用例，程序员可以像Junit测试那样使用使其快速自动化，使用FitNesse来代替Junit进行TDD，所编写的代码有助于在FitNesse设施中进行测试。
凭借短期迭代，我们可以试用各种自动化方法、评估结果并根据需要尽快改变过程。我们可以在自动化上付出很多努力，比如几个迭代内在内部开发出测试框架或是实现出开源工具。在每个迭代结束后，看看哪些是好的，哪些是不好的。思考解决问题的方法并在下一个迭代中尝试这些方法。如果这不是正确的方案，请在随后几个迭代中尝试其他方法。不要将太多资源投入到一个工具当中，不要用一种工具进行过多的测试，这样就无法切换工具了。在众多的开源与商业工具之间，再加上程序员编写的土生土长的测试工具，我们没什么理由找不到合适的工具。
Lisa的故事
我早期所在的XP团队努力尝试为一个基于Java的Web应用找到自动化客户验收测试的方法。对于敏捷团队来说，工具匮乏的日期已经一去不复返了。首先，我们尝试了一个能够模拟浏览的开源工具，但它缺少我们需要的特性并且不够健壮。
我们决定在随后的两个迭代中使用单元测试工具来测试GUI后的代码。通过这两个迭代，我们觉得时间分配很充裕，可以很好地尝试工具，但如果它不是正确的方案则时间就变少了。客户发现单元测试很难阅读，此外GUI中还有一些逻辑是该工具所无法测试的。
在回顾过程中的另一场讨论结束后，我们决定在接下来的两个迭代中使用我在之前项目中曾经使用过的GUI测试工具。Java程序员发现其运行速度很慢，因为该工具使用了一个私有的脚本语言，但其完全符合最小化的自动化需要。在两个迭代约束后，我们认为它不太理想，但那时还没有更多的选择，它就是我们能找到的最好的工具了。
事后，我们本应该再去寻找更好的工具，或许我们还能开发出自己的测试工具。我们使用该工具可以自动化单元级别上60%的回归测试，当时看起来这已经非常了不起了。如果我们能再主动一点，我们本可以做的更好。
迭代是非常有好处的。他们使得逐步的方式变得更加简单。如果想法不成功，那么很快就能知道答案并采取其他方式。不要害怕寻找，但如果工具已经够用了，那就不要再去寻找完美的方案了。
若没有自动化，敏捷开发将寸步难行。整体团队运作方法意味着有很多技能和资源可用于实现自动化之道。以团队的名义意味着代码在设计时会更多的考虑到可测试性。程序员、测试人员以及其他的团队成员会联合起来进行自动化测试，汇集不同的视角和技能。
整体团队运作方案有助于克服恐惧。团队都会选择以自动化作为起始点。了解其他人拥有着不同的技能和经验会给予我们勇气。可以寻求帮助会给我们信心，我们能够通过自动化测试获得足够的覆盖率。
Lisa的故事
下面的示例是为了成功进行自动化而需要的一些辅助措施。
早期，在没有自动化测试，开发人员还在学习测试驱动开发时，我们决定使用canoo webTest进行GUI冒烟测试。我需要一些帮助来理解如何配置Webtest以运行在我们的环境中，我需要帮助从自动化构建过程中运行这些测试。我咨询了系统管理员（也是一个程序员）来寻求帮助。我们很快就在构建当中积累了一个测试套件。
接下来，我想使用fitnesse完成GUI后面的功能测试。不得不保持耐心，因为程序员们仍然在解决自动化的单元测试。团队同意试验该工具，但却很难挤出时间。我找到了一个适合于fitnesse测试的故事并咨询程序员是否可以与其结对来尝试fitnesse测试。他同意了，接下来就实现了fitnesse下的一些自动化测试。那个程序员发现它很简单，也值得使用，并为团队的其他成员做了一场报告。
之后，我就能比较轻松地说服每个程序员为所从事的故事编写fitnesse测试了，还能让其看到结果。Fitnesse测试发现了程序员没有考虑到的测试用例，他们立刻就能看到其带来的好处。当团队的每个成员都具备了使用该工具的经验后，他们不仅变得热衷于自动化测试，还以能够简化编写fitnesse设施的方式设计代码了。
在我们的ruby专家（设计了大多数watir测试套件）离开公司时，我很担心该如何维护大量的测试套件以及如何编写新的测试。我的Ruby技术不如他（再加上我们只有一个测试人员了，时间也是个问题）。团队每个程序员纷纷走出去，买了ruby书，在修改代码时，一旦我遇到了脚本上的问题，他们都会过来帮我。其中一个程序员甚至在我没有时间的时候编写了一个全新的脚本来测试新的故事。在我们招聘到一个新的测试人员时，他和我都可以处理Watir脚本，这样程序员们就不用管这些事情了。
我知道我可以求助于团队中的其他成员帮我完成自动化相关的任务，整个团队 都认为自动化占据了很高的优先级，这样程序员在设计代码的时候总会考虑到可测试性问题。这是整体团队运作方案的一个鲜活例子。
专门的面向技术的测试（如安全或负载测试）需要团队外部专家的帮助。一些公司拥有专家团队可以帮助产品团队。即便能够利用上这些资源，敏捷团队也应该保证完成所有类型的测试。如果团队成员参与了创造性的过程，那么他们会发现这些成员已经具备了所需的技能。
一些组织拥有独立的测试团队，他们完成开发后的测试工作。他们通过测试来保证软件可以与其他系统集成，或是进行其他专门的测试，比如大范围的性能测试等。开发团队应该与这些团队紧密合作，使用所有测试的反馈来改进代码设计并推进自动化。
解决问题与实现好的解决方案都需要时间。我们必须帮助管理层理解，要是没有足够的时间做正确的事情，技术债务就会不断增长，我们的速度就会下降。以“正确的”方式实现解决方案需要花费时间，但从长远来看这么做会节省时间。想想为寻求想法、解决方案的头脑风暴以及常规培训和工作中学习所花费的时间吧。
企业的管理层对尽快产生出结果非常感兴趣，如果管理层不愿意给团队时间来实现自动化，那么请你好好权衡一下。从短期来看，不使用自动化的回归测试来交付特性会导致巨大的代价。就像团队不断积累技术债务一样，你将无法交付管理层所需要的业务价值。工作时请好好权衡一下。比如，去掉一个特性，但应该保证必要的价值，使用自动化来交付并维护更好的产品。
我们总会面临最后期限，我们总是感到时间的压力。虽然明知道不行，但按照以前那种方式进行工作的诱惑「比如手工执行回归测试等」总是存在的，永远不会在足够的时间来回到过去并修复问题。在下一个计划会议中，请拨出一些时间用在关于自动化的一些有意义的过程上。
Lisa的故事
我们的团队关注于如何将时间花在，良好的设计、健壮的自动化测试套件上，以便为探索性测试分配充裕的时间。质量（而不是速度）是我们追求的目标。我们的产品问题需要花费很大的代价来修复，因此整个公司都花费很多时间来预防这一点。有时，我们没有采取正确的设计，但在认识到这个问题后，我们并不害怕使用正确的设计将其替换掉。
很自然，业务上的妥协是存在的，业务决定了是否在风险已知的情况下继续进行。我们会清楚地解释所有的风险并给出潜在的场景示例。
下面几个示例阐述了如何花费时间做正确的事情。我们开启了一个新的主题对退休金计划的账户结果单进行了比较大的修改。程序员Vince palumbo负责收集额外的数据用于结单上。他决定为数据收集功能编写健壮的单元测试，即便这意味着故事不得不持续到下一个迭代中。编写单元测试花费了他相当多的时机和精力。而测试代码也是非常复杂和难以实现的。几个迭代过后，另一个程序员Nanda Lankalapalli开始了与数据收集相关的另一个故事，令人惊讶是，他开发了新的单元测试，他可以快速做出改变，由于单元测试就绪，测试代价集聚调整。
总之，我们发现忽略了一个边际情况：账户值改变的另一些计算不正确。自动化的单元测试和大量的探索性测试都不足以捕获所有的场景。拥有这些测试意味着Vince可以编写正确的代码并相信现在的代码是正确的。
最近的另一个例子是关于入账检查处理。业务想要将两个处理步骤缩短为一个，这意味着钱可以提前两天打到退休金计划账户中。现有的过程都是由遗留代码编写的，没有单元测试。我们讨论是否采用新的架构重写整个过程。产品所有者担心这么做的时间太多了。我们认为修改现有代码与完全重写所花费的时间是差不多的，因为旧代码实在是太难读懂了，还没有单元测试。我们决定重写代码，这不仅会降低该关键功能的风险，还有机会花费较少的代价增加额外的特性。到目前为止证明这种策略是正确的。
让自己成功，以可承受的节奏工作。离开前或是最后遇到了大麻烦时请花些时间进行重构。作为测试人员，我们总有不同的任务要完成。如果你在学习一种新工具或是自动化新的测试，那么请不要同时进行多任务处理。找一大块时间并集中精力，虽然这很难。
如果业务负责人急切盼望团队完成好任务，那么请和他一起来分析问题。风险是什么？产品问题要花费多少时间解决？发布一个快速的修复有什么好处？它会增加多少技术债务？拥有自动化测试支持的健壮设计的长期ROI如何？每种方法是如何影响着公司利润和客户满意度的？无形代价【比如低质量的工作】对团队士气的影响是多少？有时业务是正确的，但我们敢打赌，你经常会发现前期投资是很值得的。
每个人的学习方式都不同，但在决定了如何自动化测试后就请开始做吧。在everyday scripting with ruby for teams,testers,and you[2007]一书中，brian marick 建议通过编写程序来学习编程。请犯错吧！问题越多，学的越多。找个人与自己结对会加快学习的速度，即便是两个人都不熟悉该工具或语言也是如此。
如果找不到人结对就自言自语吧！解释的过程经常会暴露出问题所在。自言自语地读着测试有助于发现其中的缺陷。
测试与产品代码一样具有价值。事实上，如果没有测试的支持，产品代码也就没什么价值了。应把对待代码的态度用在测试上。与产品代码一样使用源码控制工具。你应该总能识别出与特定版本的代码匹配的测试脚本版本。
结对、重构、简单设计、模块化与面向对象设计、良好的标准、尽最大努力保持测试的独立性----优秀代码的特质也适用于优秀的自动化测试。人们有时看到敏捷开发非常混乱和松懈，但实际上它是高度自律的。通过最棒的几率保证自动化任务，小步前进，就像任何敏捷程序员编写产品代码一样，但请保持简单。如果没有良好的ROI，那么请不要编写带有大量逻辑的怪异测试脚本。那些测试还需要测试，并且需要花费时间去维护。在可能的情况下指定测试而不是编码，尽量使用最简单的方法。
测试自动化是团队工作的结晶，这句话怎么强调都不过分。不同团队成员的各种经验、技能以及观点可以搭配在一起产生出最佳的自动化方法。创新----请保持创造力。无论大家说什么，请解决自己所遇到的特定问题。
自动化工具仅仅是一块比萨而已。测试环境和测试数据是必要的组件。
