自动化的主要功能是为了回归测试。

你可能认为我手动点一次很简单啊，干嘛花那么多时间实现 ui 自动化脚本还要维护？

试想一下，如果你的产品不断的累加新的功能，你一直专注于测试新的功能，旧的功能是不是能够顾及？如果产品发布 n 次，旧的功能你是不是要重复 n 次？

接口自动化我理解不光是验证能否收到数据，现在接口自动化也建议按照业务场景来做，这样你的接口应该完成什么样的功能，在什么样的输入下，返回什么样的数据以及 code，都是验证范围，随着接口的增多，如果接口的自动化测试做的完备，ui 的自动化就可以减少一些。

好的项目我理解自动化和手动测试的比例应该是 80%：20%

敏捷测试的核心在于，测试工作不能在开发完成后再介入，而应该从需求的源头就参与进来。

基于时间短，自动化测试还不完善，可以从下面几个方面入手：

1. 需求分析阶段，和业务分析师一起写用户故事，参与到早期的需求讨论环节，尽可能多的了解需求
2. 增加用户故事启动环节，和业务分析师，开发工程师，一起确认需求，确保大家理解一致
3. 增加开发环境验证环节，开发人员完成用户故事后，在开发机器上多角色一起进行快速验证，这样可以节省部署流水线出包后修复 bug 的时间
4. 增加 showcase 环节，搜集客户反馈。

总的来说，敏捷 QA 要参与到软件开发的全流程中。