敏捷测试和瀑布测试
我仍然记得那天,我们的交付经理宣布从下一阶段开始,该项目将变得敏捷。 在参加了一些培训并进行了一些在线研究之后,我意识到,作为一名传统的测试人员,从Waterfall迁移到敏捷的测试团队是提升我的职业生涯的最佳学习体验之一。 在敏捷测试中,存在某些挑战,我的角色和职责增加了很多,工作场所要求以前所未有的速度发展。 除了帮助我学习自动化工具以及提高我的领域和业务知识外,它还帮助我与团队建立了联系并积极参与了产品创建。 在这里,我将分享作为传统测试员从Waterfall迁移到Agile所学到的一切。
敏捷测试与传统测试有何不同?
测试人员从瀑布式迁移到敏捷项目时要学习的第一件事是,传统测试与敏捷测试之间的明显区别。 在项目计划,执行和测试人员在团队中的参与中可以清楚地看到差异。 让我们看看细节上的差异。
基本思想
在传统的软件开发生命周期中,项目的主要原理是仅在修复了缺陷之后才发布应用程序。 但是,敏捷处理的是迭代方法,在这种方法中,测试人员必须在每次迭代时检查质量标准。 最近,已证明采用Shift-left测试可以加快敏捷测试的速度。
该过程如何进行?
在传统的Waterfall方法中,测试人员在项目开始时进行需求收集,然后在开发完成时再次进行。 截止日期保持固定,并且如果开发团队延长了截止日期,则测试持续时间会缩短,从而跳过了一些重要的测试阶段。
但是,在敏捷测试中,开发和测试被整合到每个阶段。 测试人员在每个冲刺阶段都与开发人员一起工作,并且由于需要更快的交付速度,因此在许多情况下,手动测试已被自动化测试所取代。
团队如何运作?
瀑布方法在很大程度上取决于指定要求的文档。 验收测试通常由利益相关者或最终用户完成。
另一方面,敏捷高度依赖于项目中每个人之间的沟通。 接受条件是在用户故事中定义的,因此,接受测试是由测试人员完成的。 除了手动或自动测试之外,测试人员还必须在多个领域内熟练。 以下是高效软件测试人员的17大技能 。
软件发布如何成功?
软件的成功或失败矩阵取决于测试的进行方式。 无论如何,如果出现一些关键缺陷,则该项目别无选择,只能进入红色区域。
在敏捷中,提供了持续的反馈并与利益相关者一起安排了演示,从而在截止日期临近时减小了任何关键依赖项的范围。
我开始进行敏捷测试时发现了什么?
除了新的工作文化和学习测试以外,还学习了许多新东西,当我加入敏捷测试团队时,我发现了许多其他新东西。
每日站立会议
在我以前的项目中,通常每天或每周召开会议,讨论目标,团队中的任何新变化或经理想要与我们共享任何信息。 在敏捷中,让我印象最深刻的是日常站立会议。
- 站立会议通常每天早晨举行15至30分钟。
- 持续时间取决于团队规模。
- 每个团队成员被问3个问题
-
- 您前一天做了什么?
- 参与者包括整个团队,包括利益相关者和Scrum主管。
- 会议的主要目的是弄清整个团队的进度,并消除任何障碍。
- 为了解决任何障碍,Scrum主管必须承担责任。 如果超出他的范围,他应该确保其他人必须承担责任。
测试程序分为四个象限
从Waterfall迁移到Agile时,最让我惊讶的是整个测试过程分为4个象限。
这是检查代码质量的初始安全测试程序。 测试人员提供即时反馈,并在此基础上,开发人员继续工作。 它包括
- 单元测试以检查一段代码是否满足要求。
- 测试组件体系结构,以确保它们组合在一起时可以工作。
第二象限主要由业务驱动。 测试人员获得了要求,以便可以开始编码而没有任何障碍。 开发人员在开始工作时要牢记业务目标。 它包含
第三象限的目的是实现Q1和Q2的目标。 自动化测试用于评估,同时牢记产品的实际使用情况。 即使产品尚未完成,仍会安排演示以确保根据业务需求进行开发。 这包括
这主要包括测试非功能性规格,例如安全性,性能等。测试人员在最终交付成品之前,使用此象限检查预期的非功能性质量。 这包括
- 测试基础架构和数据迁移
- 测试负载和可伸缩性
- 测试基础架构
- 性能和压力测试
- 用于确保身份验证和黑客防范措施的安全测试。
战略是敏捷测试的关键
当我们计划从瀑布式测试过渡到敏捷测试时,必须制定合理的策略来帮助事情有条不紊地进行下去。 敏捷测试策略通常包括四个阶段。
在此阶段,初始设置任务已完成。 这包括工具的安装,需求分析以及确定执行特定任务的资源。
- 建立业务案例
- 分析需求并创建用例。
- 风险分析总结
- 在计算成本估算后准备一个初步项目。
这是项目中最重要的部分,因为大多数测试过程都在此阶段执行。
- 在每个冲刺中,团队都会实施敏捷建模,Scrum,敏捷数据和其他敏捷实践。
- 根据优先级对需求进行排序,并且团队在每个冲刺中执行最优先的测试。
- 测试分两个阶段进行。 开发人员测试,由开发人员完成编码后完成。 他们验证服务集成测试和单元测试。 敏捷验收测试由测试人员执行。
- 在敏捷验收测试中,不仅项目的测试团队,而且利益相关者的测试团队也一起执行测试用例。
该产品已部署到生产中。 团队进行了一些活动,例如
- 培训最终用户
- 备份资料
- 营销发布
- 最终用户和系统文档的文档。
产品进入生产阶段
- 如果添加了任何新模块,则会进行常规测试。
- 如有任何错误或用户疑问,则由生产支持团队解决该问题。
从一开始就成为SDLC的一部分是集成的敏捷测试
当我在遵循Waterfall模型的项目中工作时,测试人员在所有方面都被抛在后面。 他们只参与了
- 在客户之前,需求收集阶段已交付了最终的软件需求规范。 交付后,我们必须分析要求,如有任何疑问,请与利益相关者或广管局联系。
- 开发阶段完成后。 我们必须测试模块并报告质量检查工具中的错误。
这样做的主要缺点是协作不当和测试窗口狭窄。
- 开发人员和测试人员之间没有合作或适当的沟通。 测试人员是有些人,他们的工作是在开发人员的辛勤工作中发现错误。
- 没有给测试人员任何适当的时间范围。 如果开发团队延长了截止日期,那么测试人员必须减少工作时间,并跳过一些重要的测试阶段。
但是,从一开始,敏捷测试就要求测试人员和开发人员一起工作,而且两者都必须彼此做部分工作。
加快自动化步伐,加快敏捷测试
敏捷开发就是开发正确的产品并降低开发产品时的相关风险。 总是欢迎进行更改,并保持时间复杂性在敏捷的测试中,要求自动化。 除了视觉回归测试和可用性测试外,大多数其他测试过程(如单元测试,功能测试)现在都已实现自动化。
这使我们学习了Selenium,UFT,Appium等新工具。测试人员还必须学习如GitLab,Jenkins,Codeship等CI / CD工具,以保持行业领先地位。 这使我意识到,当我从Waterfall迁移到Agile时,测试变得更具挑战性,这使我有机会磨练自己作为测试员的技能。
更好地理解业务逻辑
为了编写有效的测试用例场景,尤其是在进行探索性测试时,优秀的敏捷测试人员必须对域应用程序的工作方式具有适当的了解。 当我成为敏捷团队的一员时,我能够与开发团队更加紧密地合作。 我对开发术语变得更加熟悉,对架构图进行了探索和更清晰的了解,并帮助创建了创新的业务案例场景。
为了创建更少的,具有更大覆盖范围的测试用例,测试人员最终需要对业务逻辑有一个清晰的了解。 这就需要与开发人员和业务分析师进行及时的讨论,阅读规范并同时使用该应用程序。 最终,这不仅增加了他们的技术知识,而且增加了他们的领域和业务知识。
从瀑布式测试到敏捷测试的先决条件
除了愿意学习并准备深入研究业务之外,从瀑布式测试过渡到敏捷测试之前,我几乎不需要学习任何东西。
自动化工具
敏捷要求速度。 我再也不能浪费时间每天,每周或每次冲刺执行重复测试。 有人呼吁加快严格的回归测试。 我意识到要成功地从瀑布式测试过渡到敏捷测试,我必须学习自动化工具,例如
- Selenium WebDriver –最终的开源测试自动化工具,可最大程度地减少自动化网站测试的挑战 。
- HP UFT –用于执行功能测试
- Appium –用于测试移动应用程序
也。 单元测试和BDD测试工具,例如JUnit,Pytest,JBehave,Cucumber等。
项目管理工具
使用HP Quality Center报告和跟踪错误的日子已经一去不复返了。 从瀑布式测试过渡到敏捷测试之前,我们必须学习顶级的协作工具 ,这些工具可帮助进行错误报告以及项目管理,例如
- 松弛
- 吉拉
- 螳螂
跨浏览器测试对于处理浏览器差异至关重要
在开发过程中结合了对每个sprint的测试后,我意识到,一个浏览器对另一个浏览器来说,网站可能看起来有所不同。 在数百个浏览器上进行测试可能非常耗时,并且可能会耗费大量基础架构和带宽。
但是,有一些基于云的浏览器兼容性测试工具,例如LambdaTest,您可以使用它们跨运行在各种设备上的2000多种真实浏览器进行测试。 LambdaTest还通过其云端的Selenium Grid提供基于Selenium的自动化测试,以帮助您跨数百种浏览器-设备-OS组合最大程度地测试应用程序。
我在敏捷测试中面临的挑战
好吧,由于方法不同,因此有很多新东西需要学习,要学习这些新东西,对我来说,实施这些挑战会带来一定的挑战
学习编程语言和开发程序
在敏捷中,没有特定的术语称为测试人员或开发人员。 开发人员必须进行部分测试,测试人员也必须进行部分开发。 由于敏捷要求快速交付,因此几乎没有进行手动测试的范围。 我们必须基于该项目学习许多自动化测试工具以及诸如C#或Python之类的编程语言。 测试人员还必须学习使用部署和集成工具,如Git,Jenkins等。
小期限
更快的交货意味着更短的期限。 每个冲刺和用户故事都有一个非常严格的期限,团队必须在该期限内完成开发,执行所需的测试方案以及与利益相关者或管理层安排演示。 即使满足所有要求,如果利益相关者不满意,我们也必须照顾他们的疑虑并解决问题。
需求的频繁变化
敏捷对于利益相关者是灵活的,因为如果他们对团队交付的内容不满意,那么敏捷就可以让他们自由地更改需求。 但是,在某些情况下,这对正在开发该产品的团队不利。
假设正在开发一个网站,并根据需求创建了交互式导航。 但是,在安排好演示之后,利益相关者说它看起来不太好,他们希望使用基于视差的导航。 在这种情况下,开发团队必须花费一些额外的时间来创建导航系统,而测试人员必须对其进行测试。 最终导致浪费他们以前的努力。
无缝协调
由多个团队交付各个方面的信息,同时进入项目。 事实证明,协调是释放每个团队最大潜力的关键。 协调有助于以更快的速度推动开发和测试,并提高团队之间的透明度。
结论
作为测试人员,从瀑布式测试过渡到敏捷测试可能具有挑战性,一开始可能看起来有些吓人。 但是,它使您能够进行大量学习。 如果您要在敏捷中进行测试,那么工作中的每一天都会为您提供许多学习的知识,建议和实施创新思想的范围,并最终推动该行业的发展。 和我一样,如果您不熟悉敏捷测试,请不要害怕或困惑。 把握机会,并从每一个机会中学习。 在项目中展示您的技能和创新,这将帮助您促进职业生涯,成为熟练的手册和熟练的自动化测试员 。
翻译自: https://www.javacodegeeks.com/2019/03/learned-while-moving-waterfall-agile-testing.html
敏捷测试和瀑布测试