大家好，我是阿萨。前2期我们说了敏捷测试计划，敏捷测试策略以及敏捷测试四象限。 这一期我们就讲挑战和风险，什么挑战呢? 那就是敏捷开发流程中我们这些QA 的痛点，也称为挑战。 另外不同于传统的自动化，我们看看敏捷开发流程中的自动化测试的风险。
一. 敏捷开发流程中QA的挑战
- 敏捷宣言中说，工作的软件 胜于详尽的文档。 因为文档优先级很低，所以敏捷开发中出错概率更高。 最终给QA团队带来更多压力。
- 快速开发，所以测试分析新需求的时间更短了。测试设计以及分析特性满足需求的时间更少了。
- 测试在敏捷要扮演半个开发人员的角色去分析需求场景和组件测试。
- 测试执行时间被高度压缩。
- 准备测试计划时间更少
- 回归测试，就更加少了。
- 从质量守门员的角色要变成为质量的合作伙伴
- 要面对更多的需求更新和需求变更。
看完是不是觉得这就是我们敏捷下测试人员的最紧迫的痛点?
二. 敏捷过程中的自动化风险
UI 自动化 让我们对端到端验证更有信息。但是UI自动化执行时间长，维护成本高，甚至写UI 自动化耗费人力更多。所以UI 自动化在很长一段时间都很难产生正向收益。UI 自动化稳定性较差，对环境依赖程度高。同时失败用例的维护以及产品更新后导致UI 自动化 需要更新所需要花费的人力更多。同时 排查误报用例更是难上加难了。
如果UI 自动化没有CI、CD启动，完全靠人工去启动运行的话，很容易因为版本更新，环境配置等因素影响而失败。UI 自动化是为 回归测试 准备的，所以探索性测试和其他测试类型仍然需要继续做。许多商业上可用的自动化工具提供了简单的特性，比如自动捕获和重放手动测试用例。
这种工具鼓励通过UI进行测试，并导致测试本身的脆弱和难以维护。同样，将测试用例存储在版本控制系统之外会产生不必要的复杂性。为了节省时间，很多时候自动化测试计划没有计划好或没有计划，这导致测试失败。
在测试自动化过程中，测试配置和删除测试数据来恢复环境通常被忽略，而执行手动测试时，测试配置和恢复环境听起来是无缝的，无需做额外的事情。甚至无需做什么。生产力指标，例如每天创建或执行的测试用例的数量，可能会产生严重的误导，并可能导致在运行无用的测试上进行大量的投资。
投入产出比太低敏捷自动化团队的成员必须是有效的顾问:平易近人、合作、足智多谋，否则这个系统很快就会失败。因为会有各种各样的问题。自动化可能提出并交付测试解决方案，相对于所提供的价值，这些解决方案需要进行太多的持续维护。
自动化测试可能缺乏构思和交付有效解决方案的专业知识。它仅仅是实现某个测试用例的自动化而已。业务需求和客户需求可能并不涉及。从上面的描述中我们可以看出，自动化的高维护性，低健壮性和稳定性。 以及对测试自动化配置和恢复环境初始状态都会是阻拦UI 自动化进程的大老虎。
三 . 结论
结合前几期的内容，我们得出的结论有：敏捷测试包括在软件开发生命周期中尽可能早地进行测试。它要求客户高度参与。代码应该足够稳定，可以进行系统测试。可以进行广泛的回归测试，以确保bug得到修复和测试。最重要的是，团队之间的沟通使敏捷测试成功。
如果内容让你有收获，欢迎点赞关注
