敏捷转型可帮助企业在任何市场形势下管理变化并寻求新兴机会。这种方法的关键要素是实现敏捷测试自动化。
敏捷转换和测试
通过敏捷方法,软件功能被开发并在频繁的迭代(称为sprint)中发布。
从测试的角度来看,这些短而频繁的迭代显着限制了进行回归测试的时间,即确保新功能不会在现有软件中产生无法预料的问题。
为了实现敏捷性,开发人员和测试人员都需要能够敏捷地工作-测试自动化是解决方案的一部分。但是这在实践中如何工作?
在本文中,我们讨论了如何将测试自动化集成到敏捷测试中。
如果您不熟悉自动化,请收听播客集: 成功实现自动化有哪些要求 有关测试自动化和最佳实践的介绍,您可以在开始自动化之旅时使用。
敏捷测试的困境
必须意识到,敏捷方法包含测试人员必须处理的一些矛盾元素。
例如,测试人员应专注于测试当前sprint的新功能,并使用自动化来进行回归测试。
同时,不应(也不能)针对不稳定的软件构建测试自动化案例,并且在接近冲刺结束之前,功能通常不稳定。
这就产生了一个问题:测试人员在冲刺阶段应该集中精力于新功能,什么时候应该为这些功能建立自动化案例?
换句话说,测试人员如何在冲刺期间最好地分配时间?下图说明了该问题。
图1: 冲刺的过程。
针对当前sprint的功能构建测试自动化案例是不现实的,这有两个原因:
- 功能不够稳定,无法在冲刺结束之前进行测试
- 需求和实现可以在冲刺期间更改
如何克服敏捷测试中的挑战
相反,测试人员应专注于如何测试单个功能,并依赖于当前sprint功能的手动功能测试。
这样可以确保灵活性,并且测试人员可以避免浪费时间在冲刺期间可能会更改的功能上构建自动化案例。
然后在接下来的sprint中,应该自动执行先前sprint的功能测试用例(即回归测试)。
在这一点上,现有功能足够稳定,可以进行测试,并且通过自动测试它们,测试人员可以将精力集中在新功能上。
下图说明了如何组织冲刺以包括测试自动化。
在敏捷冲刺中要自动化什么
构造测试的常用方法是通过概述特定功能所需的手动测试来开始每个冲刺。这可以通过下面的简单思维导图来完成。
图3: 映射如何测试功能。
然后,在接下来的冲刺中,测试人员应选择应将哪些案例升级为自动化测试。
通常 自动化所有手动测试没有意义,因此您通常会自动化测试用例的子集或组合。
这里的重要部分是最大程度地降低回归错误的风险,因此,在这一点上,测试人员对产品的知识和见解至关重要。
换句话说,选择哪些测试用例应该自动化和哪些不应该自动化的过程是测试人员职业的重要组成部分。
图4: 促进自动化的特定测试用例。
在敏捷中实现测试自动化
将测试自动化实现为敏捷测试的一部分取决于几个因素。组织,Scrum团队的速度,自动化的便利性等。
理想情况下,测试团队的所有成员都应该能够参与自动测试用例的创建和维护。这确保了同质,可扩展且快速工作的团队–符合敏捷哲学。
要体验自动化工具,可以做到这一点, 开始免费试用LEAPWORK -唯一的多合一自动化平台 适用于非开发人员,技术专家和商业用户。
重要要点
- 敏捷方法包含一些矛盾的要素,这些挑战使测试人员难以在冲刺期间分配时间。
- 自动化的功能UI测试可以在sprint期间进行回归测试,但是在测试功能稳定之前,不应为软件构建测试自动化案例。
- 我们建议逐步构建一个自动化回归套件:从上一个sprint中选择测试用例以促进自动化,构建它们,然后将它们作为sprint中的自动化测试运行。
- 选择哪些测试用例应该自动化,哪些不应该自动化的过程,是测试人员职业的重要组成部分。
- LEAPWORK的自动化方法是测试团队的所有成员都应该能够参与自动化测试用例的创建和维护。
了解更多有关敏捷冲刺中的自动化和敏捷测试自动化的信息 白皮书:敏捷测试.