公司引入 “敏捷测试” 还是引入 “敏捷”，引入 “敏捷测试” 的话照公司的要求做就行了啊
每个公司可能对于敏捷的理解不一样的，最近刚好参加了 ACP 认证的培训，作为一个站在敏捷大门口的人（虽然公司内部已经号称实施敏捷 1 年多），说一些自己比较浅显的见解：
敏捷的核心在于快速应对变化，对于测试工作的挑战会大于开发工作;
敏捷依赖高度
自动化，不仅仅是测试，所以如果还是纯手工测试，肯定应付不了敏捷要求的快速迭代要求;敏捷项目中的质量保证过程可能与传统瀑布型项目有较大区别，比如质量控制的环节会提前，会加强在提交测试之前的质量控制，可以依赖一些自动化实践，比如 ATDD，BDD，同时质量控制的环节也会更丰富;
综上，建议在刚引入敏捷之前，团队可以一起来规划一下质量保证的过程，为了快速响应，工作内容，人员分工都可能都与之前不一样，仅供参考。
敏捷测试的核心在于，测试工作不能在开发完成后再介入，而应该从需求的源头就参与进来。
基于时间短，自动化测试还不完善，可以从下面几个方面入手：
- 需求分析阶段，和业务分析师一起写用户故事，参与到早期的需求讨论环节，尽可能多的了解需求
- 增加用户故事启动环节，和业务分析师，开发工程师，一起确认需求，确保大家理解一致
- 增加开发环境验证环节，开发人员完成用户故事后，在开发机器上多角色一起进行快速验证，这样可以节省部署流水线出包后修复 bug 的时间
- 增加 showcase 环节，搜集客户反馈。
总的来说，敏捷 QA 要参与到软件开发的全流程中。
敏捷测试做了一年多，有一些感悟：
- 项目初期，QA 需要参与整个项目流程，前期的需求安排与分析（帮助了解整个项目），Timeline 的各个节点（帮助制定测试 Plan），开发测试过程中的及时沟通（帮助发现 bug），因为是敏捷型，所以制定的计划会有一些改动，QA 需要根据改动进行合理的测试安排。
- 项目中期，第一个版本上线后，即可制定合理的自动化（Sanity Level），来辅助测试。对于一个敏捷性项目而言，合理的自动化是极其重要的。
- 项目后期，多个版本上线后，即项目稳定后，完善丰富自动化测试范围（Regression Level）。逐渐将手动功能测试上的一些内容转移到自动化上。 此时自动化应该包括 API，UI 和 Performance.
总结：敏捷测试对于一个 QA 的压力是比较大的，制定良好的自动化，是整个项目质量的重心所在。
测试工作最好在产品需求/创意的初期，就要求测试人员参与进来，强调参与流程的重要性，只有在了解整个产品的流程，在项目开发中无缝衔接，这样才能避免在测试短时间下出现的开发 bug 多，从 0 到 1，全面介入很重要，后续结合自动化产品测试工具，合理的安排时间。脉冲云开发平台是基于从产品的创意、需求、设计、开发、部署、测试、发布等整套的全流程的 DevOps 平台，各个任务之间相互关联，无缝衔接，全自动化。
- 尽可能多地在需求阶段发现问题规避风险；
- 编写详细的测试要点，引导开发自测，帮助开发建立质量意识；（需要得到项目 leader 的支持）
- 寻求更加有效的探索式测试方法；
- 部署分层自动化测试体系，减少重复性劳动的工作量。
公司一旦使用敏捷的开发流程，其实对测试的要求、能力都是很高的，而且压力也会变的很大；当然也会得到相应的锻炼，不管是技术层面、流程管理层面，希望测试同学都能抓住这样的机会，一起成长~~
你们开发写单测吗？