当提到可接受的测试自动化，最重要的一步是在适当的位置有一个适当的测试自动化团队框架。这篇文章对一些不同的自动化测试适用场景有一些已证明的项目——由一个自动化或者回归团队主导，以敏捷的适应性——帮助组织享受长期的测试自动化的成功。
公司发起一项新的测试自动化倡议——任何销售人员设计销售相关的工具——倾向认为他们的成功取决于完美的上线。作为一个测试自动化顾问，我喜欢提供一个真实的基于我在领域里所见的检查。如果你没有准备好，最初的上线可能是坎坷崎岖的路，但是在长期中，那不是要制造而是破坏你的测试自动化倡议。
近来我亲眼看到一些公司没有准备就开始出现测试自动化。执行这个“策略”的风险是测试者们可能要因为这些原因坚持测试自动化：
- 他们觉得没有它生活得很好
- 他们不想要（或没有时间）学习新工具
- 他们担心它太复杂而且需要获取跟上进度的努力超过了感知到的好处
一个不充分的计划——或者完全不计划——上线很明显不是最好的发起一个测试自动化倡议的最好方法。无论如何，我发现了从坚固的上线中恢复比没有一个恰当的测试自动化退队结构而去获得持续的测试自动化来得简单些。
我喜欢去为一些不同的测试自动化采用场景去分享一些已证明的实践，帮助了很多机构享受长期的成功——甚至当最初的上线不理想时。
自动化团队正一个接一个项目地上线我们的测试自动化
我能提供的最好一条建议是从小事开始，然后做大的。已证明的第一个实践是从创建自动化团队开始。
这个团队将从不同的项目迭代并且开始从最重要的测试用例起自动化。这让你证明在倡议中的进度并且让你看到了一些应用程序的改变如何影响主应用程序功能性。
我建议从最有影响力的测试用例开始：覆盖你的头等业务风险的那些。这创造了强有力的回归文件夹的建立，它提供了最快的应用程序变化是否先破坏了正在工作的功能的反馈。
自动化团队应该包含至少一位测试设计专家，他通过回顾需求并使用测试用例设计方法制定出应该被自动化的测试用例。然后，测试设计专家或者两个或三个自动化专家中的一位能评估是否需要测试数据管理，然后他们能合作指定测试用例。同时，测试设计专家将关注下一个项目。
取决于你想要测试的软件以及你定制它多少，一个自动化工程师是必要的。他们将确保常规的控制被创建然后被维护。
团队的大小将会随着扩大，取决于测试用例和团队处理的项目的数量。这些建议只是为了最初的上线。一旦上线开始进行，你们将会想开始招募尽可能多的人员。
一旦测试用例被自动化，他们能通宵在虚拟机上运行，然后在日常基础上报告执行结果。为使测试自动化加入与运转的最重要的事情是确实在执行测试用例！假如你不是正执行你的用例，你不会从它们得到任何价值，不论你的测试集设计得如何好并且它如何好地覆盖你的主要业务风险。
取决于你的公司架构（敏捷或不是，测试团队或者独立的测试员们），自动化团队可能主要以教导每个人关于上线自动化最佳实践的实施以及当他们开始他们自己的测试自动化时的需要考虑的项目多样性为主。
在测试人员开始采用测试自动化之前，必须做个决定：谁负责这些测试用例？这是主要的。假如自动化团队（或者后来回归团队）是负责的，然后他们不得不与测试人员们和商务方面做更多的沟通。假如它是测试员们的的责任，他们需要足够的时间去保证所有的测试用例在执行并且符合业务需求。每一个组织需要去决定什么是对他们最好的，取决于他们的架构和工作模式。
不管你负责哪个方向，确保节约足够的时间来沟通。一方面，新的测试用例需要被回归团队审核然后为执行而创建。另一方面，回归测试结果（尤其失败的测试用例）需要被共享使得负责的团队成员或者测试员们能审查它们并必要时更新测试。至少，确保测试员们独立地检查回归结果并做合适的调整，这样回归团队能从共享文件夹里推出新的测试用例，自己审核它们。
回归团队在每个项目上领导和指导测试员们
我所见过的最有效率的设置是建立一支初始的自动化团队，它包含一个回归团队，一旦测试自动化基金会被成立，其他就要准备驱动它向前。
回归团队仍然为在最初的项目里创建测试用例负责，维护存在的测试用例，执行测试用例，保护测试架构，并且监督拓宽的测试自动化建立和项目。你能把这个团队叫做优秀测试中心。
关于这个建立，可能有项目和更大的改变由测试设计专家指导着，他关注正确的格式并提供它应该看起来像什么的预览。他们就像软件艺术家（或者以我们为例，测试艺术家）。
回归团队是“定位群”，假如你有关于问题的疑问或者你想要引进新的创新。所有者和责任应该应该是回归团队的，因为他们有测试文件夹的最好概览。
从一个资源的角度，你在回归团队里需要高技能的人，但是你能侥幸逃离经验少的作为测试员的团队成员。假如测试员们需要比培训提供的更多的知识，他们能经常问回归团队，他们然后能通过共享他们建立起的知识提供帮助。
敏捷环境的适应
对于敏捷团队，测试自动化被团队里的敏捷测试员驱动。这个人应该比一个自动化专家更先进——他们需要理解测试用例设计、需求、测试用例创作和执行，以及核心的测试最佳实践，并且他们需要一个测试什么以及如何有效测试它的好的理解。
我建议一个开发和测试从一个Sprint到另一个Sprint持续的建立：
当开发结束了Sprint n-1的特性，测试开始。同时，开发能持续特性2（Sprint n），等等。只是确保为修复bug和更深入改进保留时间。
我们分离开发和测试吗？
最后，当谈到架构，我想要给频繁发生的一对问题增加我的两分钱：我们的开发需要测试吗，或者我们需要分离开发和测试吗？我们在测试中使用软件开发工程师（简称SDETs）吗？
理论上，你也可以通过有开发测试来节约时间和金钱因为开发最知道代码。但是实话实说：开发从没有足够的时间去完成每个人想要完成的开发任务。假如他们也为测试自动化负责，那意味着他们甚至没有时间去完成那些任务。而且即使开发们最知道代码，你确定他们能检查边界条件吗？预计风险并尝试询问合适的问题？探究系统并把它推向失败？
我的意见是有些人不写代码更适合做这个。那些其他人关注于通过应用程序获取实际的业务目标并尝试思考每一个能导向系统一个错误的指导的可能性。从我所在领域里见过的，那通常不是一个开发的强项。
旋转桌子
所有这些建议是基于我的帮助用户适应测试自动化的个人经验。我知道每个读者可能有关于这的不同观点——而且我鼓励你在下面去分享关于它的想法。什么帮助你最多了？你如何在你的公司建立测试自动化？你面对的挑战是什么？