随着软件行业的发展,新趋势和运营模型也随之发展,每种“软件模型”旨在在“软件开发”的每个阶段带来更高的效率。
最广泛使用的软件开发模型之一是“瀑布模型”,其中软件开发生命周期中的所有活动(计划/需求收集->软件设计->编码(开发)->产品测试)
按顺序执行。“瀑布模型”的主要缺点是,并非在每个阶段都执行测试活动。因此,仅在“产品开发”完成后才发现错误。
如果错误的严重性较小,则开发人员可以修复问题并提交更改以进行验证。如果严重性“非常高”,则情况将发生巨大变化,并且此修复程序可能会产生副作用。在这种情况下,向客户发布产品也会推迟。在这样的模型中,测试阶段位于测试生命周期的最右边。
随着不同软件模型的发展,例如敏捷模型,增量模型,螺旋模型等。人们意识到“软件测试” 的重要性。保持“一次性测试”活动涉及大量风险,因为它对项目截止日期和成本有很多影响。这种认识产生了“转移提升”的概念,即将测试阶段移至左侧,并通过让测试团队参与对项目执行至关重要的活动来赋予测试团队权力。在较早的测试方法中,测试阶段位于开发周期的末端,而在Shift-Left
方法中,测试涉及开发的每个阶段。
在传统的软件开发方法中,测试团队会如孤岛
般工作,因为他们的主要工作是通过识别错误并将错误报告给开发团队来提高产品质量。在产品计划和开发的重要阶段,几乎没有测试人员参与。通过Shift-Left
的概念,测试团队可以更多地参与产品开发的每个阶段。通过这种方法,测试团队可以与其他利益相关者进行协作,例如开发团队,产品计划团队,产品开发团队,市场营销团队等,从而在开发的早期阶段就灌输“测试思想”。由于测试团队有机会与来自不同团队的成员进行互动,因此这种加深的理解将有助于他们编写有效的测试用例 有助于提高产品质量。
因此,Shift-Left
的概念不仅有助于在产品开发的早期阶段发现错误;但它也可以帮助测试团队与其他利益相关者合作,提高领域竞争力,并提出更现实的测试案例。
将左移测试作为SDLC的一部分进行时,会带来很多好处。
Shift-Left
概念的创始人拉里·史密斯曾经提到“bugs are cheap when caught young”。在典型的测试生命周期中,测试是在产品开发周期结束时执行的。如前所述,错误修复所涉及的成本和含义将基于发现错误的时间成倍增加。根据拉里·史密斯的观点,BUG必须在发现之前就尽早发现。
一旦实施“左移”测试,就将测试视为产品开发每个阶段的组成部分。因此,每个构建都进行一次测试,以便在早期发现并修复错误。一旦代码量变多,更多细小的错误积累,模块之间的耦合越来越紧密,解决简单的问题也可能会花费更多时间,并且可能会导致一些副作用。左移测试策略可以减少开发,测试和修复的总成本。
Shift-Left
方法可确保项目的不同利益相关者之间及时进行沟通。开发人员可以合作进行浅谈单元测试和集成测试的开发。自动化是Shift-Left
测试的重要组成部分,借助自动化脚本,测试团队可以一天执行多次测试。以“BUG”形式提供的产品反馈,这有助于提高代码质量(以及通过开发测试用例和测试套件来提高代码覆盖率)。
这样可以减少在生产阶段遇到的问题数量,这意味着通过严格的代码质量检查可以提高整体代码质量,从而确保向客户交付“更稳定的最终产品”。
“向右移”和“向左移”测试方法之间的根本区别在于,测试团队需要参与软件开发的“每个关键阶段”。从单位在开发环境中测试,以移植到测试环境推动最终代码到生产环境之前。但是,实施这种方法比做起来容易做起来难,因为测试团队需要走出“舒适区”,并且每个利益相关者都需要转变思维方式,以便他们可以与测试团队合作以成功完成项目。
Shift-Left
测试,测试团队将与开发团队紧密合作,以提出自动化测试案例。通过采用这种方法,将改善“团队之间的协同作用”,这对于实现行为驱动开发(BDD)和测试驱动开发(TDD)是非常重要的方面。Shift-Left
方法,开发人员可以通过集中精力同时进行开发和测试来承担更多责任。正确执行Shift-Left
测试可以提高(开发人员,测试人员等)领域的技能,并改善团队内部的沟通,这对于任何项目的成功都是至关重要的。
左移测试可以通过4种不同的方式进行:
sprint
中执行的。它主要用于开发测试,而不用于操作测试。敏捷/DevOps左移测试正在逐渐普及,根据项目要求和进度在实施DevOps中使用这种左移测试方法。总而言之,左移测试更多的是关于每个阶段实施连续测试。