71%的企业正在使用敏捷开发方法。敏捷强调持续集成，以经常产生增量价值。尽管这种策略在理论上很奇特，但它涉及到测试人员的大量回归测试。维护所有应用程序的功能，并提供稳定且持续的测试帮助，就成为了测试团队头疼的问题。尤其是当应用程序正朝着不断扩展的方向发展时，更是难以应付。
大多数团队使用测试左移的方法，即在集成点上使用自动测试进行快速检查。当所实现的代码被推送以与主分支合并时，便可以自动启动一系列测试。在这个过程中，我们看到了大多数开发团队的基本现实，其中的挑战不仅在于人数，还在于可用的技能、支持性工具、技术、非支持性流程等。
在每一个不同团队中，测试自动化的价值主张都以一种独特的方式得到了推动。为什么呢？如果计划得不好，测试自动化就会变成时间密集型活动。这不应该是一件做一次就忘记的事情，测试自动化需要持续的关注和维护。
测试自动化自主性的核心重点是谁负责编写测试脚本、定期运行测试脚本、决定测试环境、维护测试和扩展这些测试。在不同需求的不同团队，存在着多种形式的组织形式和自主权，而不同的组织形式也各有利弊。
让我们研究一下一些常见的测试自动化团队结构。
1. 开发人员领导的测试自动化团队
在一些小的敏捷研发团队中，通常会因无法获得专用资源而受到影响，团队成员扮演多个角色来完成测试任务。这些通常是充满活力和自我驱动的环境，没有建立正式的流程，团队成员只是根据他们认为正确的方式执行任务。在这样的队伍中很难找到统一的做法。
在这些情况下，开发人员拥有编写一些自动化测试以及单元测试的所有权。大多数UI开发人员还负责前端和端到端测试。
优势：
- 自我管理和自我驱动
- 测试代码是随着开发而编写的
- 良好的测试代码原则
- 失败的测试可以在开发期间内修复
弊端：
- 错过了各种端到端的测试场景
- 尝试通过调用DB或直接登录来避开真实验证，以编程方式完成任务
- 添加的测试场景和数据有限
- 定期维护失败的脚本需要不断跟进
- 一段时间后可能会被忽视和遗忘
2. 测试自动化小组分工负责
在稍大一些的敏捷研发团队中，一般都会分配数名单独的测试人员。在这种情况下，测试人员必须负责新功能测试、执行回归、支持非功能测试等，并可用于为正在进行的sprint计划的任何热修复/升级/迁移等提供支持。可以采用拆分方法，开发人员将为所有新功能编写自动化测试，并将测试代码交给测试同事进行执行、管理和维护。
优势：
- 开发和测试代码在sprint中齐头并进
- 实施了良好的代码实践
- 共同努力，减轻单人负担
弊端：
- 测试覆盖范围的妥协
- 增加了开发人员的责任以及单元测试
- 紧迫的优先级容易分散开发人员的注意力
- 维护责任为测试工程师带来更多工作
- 需要提高测试工程师管理和维护代码的技术技能
3. 测试人员领导的自动化团队
在人力资源不是问题的组织中，每个scrum团队有更多的更专业的测试工程师。测试工程师全权负责编写、运行、维护和升级测试脚本。在scrum团队中，这种测试自主权通常是最受欢迎的。然而，这个过程也有可能变得更加困难，因为在大型敏捷团队中有太多的集成点，如果没有仔细识别和规划测试用例，可能会降低自动化测试的覆盖度，从而降低了自动化测试结果的可信度。
优势：
- 明确规定了测试自动化的责任
- 对自动化需求和场景覆盖率的分析得到了足够重视，且时间、精力、工具和技术等方面也有一定保障
弊端：
- 测试代码的合理性取决于测试工程师的技术技能
- 这可能是资源密集型的工作，随着应用程序的增长，将需要更多的测试人员和精力
4. 外包（QaaS）测试自动化团队
如今，很多组织更频繁地选择外部测试服务，因为它们希望有更多的时间专注于创新，并在制定扩张战略时保持灵活性。由于竞争激烈，交付时间越来越短，公司无法将时间花在内部人才培养上，因为这是一项昂贵且资源密集的活动。通过把测试活动外包，将大量责任转移给测试服务提供商。
优势：
- 所需技能随时可用
- 测试和测试自动化由服务提供商负责
- 通过测试自动化实现测试覆盖，团队可能只需要更专注于目前的交付
弊端：
- 团队/组织中的某个人应领导、参与有关测试的讨论
- 领导人员应充分了解服务提供商的期望和测试执行的前提条件
- 需要对准备和执行的测试进行定期审核
- 需要清楚地讨论将来要移交的测试代码和其他工件
最后的想法
不用说，测试自动化是敏捷团队完成最大化回归测试的关键。这是一项重要的测试活动，不容忽视。在决定测试自动化的具体策略之前，项目团队应该评估他们当前的情况。
尽管大型组织可能会根据需要雇佣更多的测试人员，但他们偶尔会遇到一些麻烦，导致无法及时为项目找到技术熟练的测试人员。而小型企业必须保持较低的运营费用，因此它们无法真正投资于测试工具、测试技能的提升，这时外包测试可能是它们的一种选择方式。
