从瀑布测试走向敏捷测试的过程中我学到了什么


我仍然记得有一天,我们的交付经理宣布,从下一阶段开始,我们的项目将是敏捷的。在参加了一些培训并做了一些在线研究之后,我意识到作为一名传统的测试人员,从一个瀑布测试团队到一个敏捷测试团队是提升我职业生涯的最佳学习经历之一。在敏捷测试中,有一些挑战,我的角色和责任增加了很多,工作场所需要一个前所未有的速度。除了帮助我学习自动化工具以及提高我的领域和业务知识之外,它还帮助我接近团队并积极参与产品开发。在这里,我将分享我作为一名传统测试人员从瀑布式走向敏捷所学到的一切。

敏捷测试与传统测试有何不同

当从瀑布测试转向敏捷测试时,测试人员学到的第一件事就是传统测试和敏捷测试之间的明显区别。在项目规划、执行和测试人员在团队中的参与中,可以清楚地看到差异。让我们看看细节上的不同。

Image Source

基本思想

在传统的软件开发生命周期中,项目的主要原则是只有在缺陷被修复后才发布应用程序。然而,敏捷处理的是迭代方法,在每次迭代中,测试人员必须检查质量标准。最近,左移测试的采用被用来加速敏捷中的测试。

流程如何工作

在传统的瀑布方法中,测试人员在项目开始时收集需求,在开发结束时再次工作。截止日期仍然是固定的,如果开发团队延长他们的截止日期,测试持续时间会变得更短,跳过一些重要的测试阶段。

然而,当在敏捷中测试时,开发和测试被包含在每个阶段。在每一次冲刺中,测试人员都与开发人员一起工作,由于它要求更快的交付,在许多情况下,手工测试被自动化测试所取代。

团队如何工作

瀑布方法在很大程度上取决于指定需求的文档。验收测试通常由涉众或最终用户完成。

另一方面,敏捷高度依赖于船上每个人的交流。验收标准是在用户故事中定义的,因此验收测试是由测试人员完成的。除了手动或自动化测试,测试人员必须精通多个领域。

软件发布如何成功

软件的成败取决于测试的进展。如果出现一些严重的缺陷,项目别无选择,只能进入红色区域。

Image Source

在敏捷中,持续的反馈被提供,演示被安排给涉众,当截止日期越来越近时,减少了任何关键依赖的范围。

当我开始在敏捷中测试时,我发现了什么

除了新的工作文化和学习测试之外的许多新东西,当我进入敏捷测试团队时,我还发现了许多新的东西。

每日站立会议

在我以前的项目中,每天或每周都会召开会议,讨论目标、团队中的任何新变化,或者经理是否想与我们分享任何信息。在敏捷中,给我印象最深的是每天的站立会议。

  • 站立会议通常在每天早上进行15到30分钟,持续时间因团队规模而异。
  • 每个团队成员都会被问3个问题
    • 前一天你做了什么?
    • 今天你会做什么?
    • 有什么障碍阻碍你的成果吗?
  • 参与包括整个团队,包括涉众和Scrum大师。
  • 会议的主要目的是清楚了解整个团队的进展,并消除任何障碍。
  • 为了解决任何障碍,Scrum大师必须承担责任。如果这超出了他的职责范围,他应该确保由别人来承担责任。

Image Source

测试程序分为4个象限

从瀑布模式转向敏捷模式时,最让我惊讶的是,整个测试过程被分成了4个象限。

象限1

这作为检查代码质量的初始安全测试程序。测试人员提供即时反馈,在此基础上,开发人员继续他们的工作。它包括

  • 单元测试检查一段代码是否满足要求。
  • 测试组件架构,以确保它们结合在一起工作。

象限2

第二象限主要由业务驱动。测试人员得到了需求,这样编码就可以毫无障碍地开始了。开发人员在开始工作时牢记业务目标。它包括

  • 线框或原型的用户体验测试。
  • 测试工作流示例和可能的场景。

象限3

第三象限的目的是实现Q1和Q2的目标。自动化测试用于评估,记住产品的实际用途。即使产品尚未完成,演示也是为了确保开发是基于业务需求完成的。它包括:

  • 协作测试
  • 用户接受度测试
  • 探索性测试
  • 可用性测试
  • 成对测试,包括利益相关者或客户。

象限4

这主要包括测试非功能规范,如安全性、性能等。在最终交付成品之前,测试人员使用这个象限检查预期的非功能性质量。它包括:

  • 测试基础架构和数据迁移
  • 测试负载和可伸缩性
  • 测试基础设施
  • 性能和压力测试
  • 确保认证的安全测试和黑客攻击的预防措施。

策略是敏捷测试的关键

当我们计划从瀑布测试转向敏捷测试时,保持一个合理的策略来帮助事情以有组织的方式进行是非常必要的。敏捷测试策略通常包括4个阶段。

迭代0

在此阶段,初始设置任务完成。这包括安装工具、需求分析和确定执行特定任务的资源。

  • 建立了一个业务案例
  • 需求被分析,用例被创建。
  • 风险分析结束
  • 在计算成本估算后,准备一个初步项目。

开发阶段

这是项目中最重要的部分,因为大多数测试程序都是在这个阶段执行的。

  • 在每个冲刺阶段,团队实现敏捷建模、Scrum、敏捷数据和其他敏捷实践。
  • 需求按照优先级排序,团队在每次冲刺中执行最优先的测试。
  • 测试分两个阶段进行。开发人员测试,由开发人员在完成编码后完成。他们验证服务集成测试和单元测试。敏捷验收测试由测试人员执行。
  • 在敏捷验收测试中,不仅项目的测试团队,而且利益相关者的测试团队一起执行测试用例。

产品部署

该产品已投入生产。该团队开展多项活动,如

  • 培训最终用户
  • 备份数据
  • 营销版本
  • 最终用户和系统文档的文档。

生产支持

产品进入生产阶段

  • 如果增加了任何新模块,将进行定期测试。
  • 如果出现任何错误或用户查询,问题将由生产支持团队处理。

从一开始就成为软件开发生命周期的一部分对于敏捷测试来说是不可或缺的

当我在一个遵循瀑布模型的项目中工作时,测试人员在任何事情上都有点落后。他们只在需求收集阶段参与项目,在客户交付最终的软件需求规格之前。一旦交付完成,我们必须分析需求,并在有任何疑问的情况下联系利益相关者或英航。在开发阶段完成后,还会咨询他们,以测试模块并在质量保证工具中报告错误。

这样做的主要缺点是不恰当的协作和狭窄的测试窗口。

  • 开发人员和测试人员之间没有协作或适当的沟通。测试人员是一些人,他们的工作是在开发人员的努力工作中发现错误。
  • 测试人员没有得到任何合适的时间框架。如果开发团队延长了他们的截止日期,测试人员就不得不缩短他们的截止日期,跳过一些重要的测试阶段。

然而,敏捷测试要求测试人员和开发人员从一开始就一起工作,并且双方都必须做对方的工作。

借助自动化加速敏捷测试

敏捷开发就是开发正确的产品,并在开发过程中降低相关的风险。变化总是受欢迎的,为了控制时间复杂度,敏捷测试需要自动化。除了可视化回归测试和可用性测试之外,大多数其他测试程序,如单元测试、功能测试,现在都是自动化的。

这引导我们学习新工具,如硒、UFT和苹果。测试人员还必须学习像GitLab、Jenkins、Codeship等CI/CD工具,才能在行业中保持领先。这让我意识到,当我从瀑布式开发转向敏捷开发时,测试变得更具挑战性,这给了我一个磨练测试技能的机会。

更好地理解业务逻辑

为了编写有效的测试用例场景,特别是当涉及到探索性测试时,一个好的敏捷测试人员必须对领域应用程序如何工作有适当的了解和理解。当我成为敏捷团队的一员时,我能够与开发团队更紧密地合作。我变得更加熟悉开发术语,探索并获得了更清晰的架构图,并帮助创建了创新的业务案例场景。

为了创建更少的覆盖面更大的测试用例,测试人员最终需要对业务逻辑有一个清晰的概念。这需要与开发人员和业务分析师进行及时的讨论,阅读规范,并玩应用程序。最终,这不仅增加了他们的技术知识,也增加了他们的领域和业务知识。

从瀑布测试转向敏捷测试之前的先决条件

除了愿意学习并准备深入业务之外,在从瀑布测试转向敏捷测试之前,我几乎不需要学习什么。

自动化工具

敏捷要求速度。我再也不能浪费时间在每天、每周或每次冲刺的重复测试上了。有人呼吁加快严格的回归测试。我意识到要成功地从瀑布测试转向敏捷测试,我必须学习自动化工具,例如:

  • 硒网络驱动程序——最大限度减少自动化网站测试挑战的终极开源测试自动化工具。
  • 惠普UFT–用于执行功能测试
  • 应用–用于测试移动应用

还有。单元测试和BDD测试工具,如JUnit、Pytest、JBeoSource等。

项目管理工具

惠普质量中心被用来报告和跟踪缺陷的日子已经一去不复返了。在从瀑布测试转向敏捷测试之前,我们必须学习有助于错误报告的协作工具,以及项目管理,例如:

  • 松弛的
  • JIRA
  • 螳螂

跨浏览器测试是处理浏览器差异的关键

随着开发与每一次冲刺测试的结合,我意识到一个网站在不同的浏览器中可能会有不同的外观。跨数百个浏览器进行测试可能非常耗时,并且可能会耗费大量的基础设施和带宽。

我在敏捷测试中面临的挑战

因为方法不同,所以有相当多的新东西要学,学习和实现这些东西对我来说有一定的挑战。

学习编程语言和开发程序

在敏捷中,没有称为测试人员或开发人员的特定术语。开发人员必须进行部分测试,测试人员也必须进行部分开发。因为敏捷需要快速交付,所以手动测试的空间非常小。我们不得不学习许多自动化测试工具以及基于项目的编程语言,如C#或Python。测试人员还必须学会使用部署和集成工具,如Git、Jenkins等。

小截止日期

更快的交付意味着更短的截止日期。每个sprint和用户故事都有一个非常严格的期限,在这个期限内,团队必须完成开发,执行所需的测试场景,并与涉众或管理层一起安排演示。即使在满足了所有需求之后,如果利益相关者不满意,我们也必须考虑他们的顾虑并解决问题。

需求的频繁变化

敏捷对涉众来说是灵活的,因为如果他们对团队交付的东西不满意,它给了他们改变需求的自由。然而,在某些情况下,这对从事产品工作的团队是不利的。

让我们假设正在开发一个网站,并根据需求创建交互式导航。然而,当演示被安排时,利益相关者说它看起来不太好,他们想要一个视差驱动的导航。在这种情况下,开发团队必须花费额外的时间来创建导航系统,测试人员必须对其进行测试。最终导致他们之前努力的浪费。

无缝协调

多个团队同时向项目交付各个方面。协调被证明是释放每个团队最大潜力的关键。协调有助于以更快的速度推动开发和测试,同时提高团队的透明度。

结论

作为一名测试人员,从瀑布测试转向敏捷测试可能会很有挑战性,而且一开始看起来可能有点吓人。然而,它赋予你巨大的学习能力。如果你在敏捷中测试,那么工作中的每一天都向你展示了许多要学习的东西,建议和实现你的创新想法的范围,并最终在行业中前进。就像我一样,如果你是敏捷测试的新手,不要害怕或困惑。抓住机会,从每一个机会中学习。在项目中展示你的技能和创新,这将帮助你作为一名熟练的手工和自动化测试人员推进你的职业生涯。