QA如何通过左移和右移实现更好的质量

2024软件测试面试刷题，这个小程序（永久刷题），靠它快速找到工作了！（刷题APP的天花板）-CSDN博客文章浏览阅读2.1k次，点赞85次，收藏11次。你知不知道有这么一个软件测试面试的刷题小程序。里面包含了面试常问的软件测试基础题，web自动化测试、app自动化测试、接口测试、性能测试、自动化测试、安全测试及一些常问到的人力资源题目。最主要的是他还收集了像阿里、华为这样的大厂面试真题，还有互动交流板块……https://blog.csdn.net/AI_Green/article/details/134931243?spm=1001.2014.3001.5501大家好！我叫Soogwang Chae，在 LINE 担任QA。我们正在通过各种渠道进行访问，以扩大与LINE以及LINE之外的其他QA人员的交流，并且我们希望将来能够通过LINE工程博客与许多人就各种QA相关主题进行交流。在本文中，我将探讨QA从“质量保证”转变为“质量协助”和“质量倡导者”的过程，以及如何通过“左移”和“右移”方法来确保更好的质量。

为什么QA（质量保证）不能保证质量？

传统上，质量是通过制定质量标准并仅发布符合这些标准的产品来保证的。然而，随着时间的推移，我们面临着必须更频繁、更高水平地交付产品的情况，并且很难像以前一样实现这些相互矛盾的目标。事实上，由于活跃设备如此之多，并且支持近 18,000 种不同的设备型号，LINE 的发布周期为两周。 

在这种情况下，即使产品通过了测试用例，在用户实际使用的生产环境中也可能随时出现与基本功能相关的Bug，并且很难回应用户对新功能的投诉。以下是通过分析 2022 年上半年 LINE Android 用户留下的评论计算出的前 6 个否定关键词。

现在很难使用传统的质量保证方法来应对。通过更频繁的发布来实现更高的质量需要开发组织变得更加敏捷，而 QA 也开始设计多种方法来变得更加敏捷，以应对开发过程中的这些变化。在这个运动中，质量保证问题不再被认为是仅仅QA的问题，而是整个开发团队乃至整个项目的问题，相应地，QA的角色从质量保证转变为支持。

尝试新事物作为 QA（质量协助）而不是 QA（质量保证）

随着 QA 转变为支持质量的角色，开发过程中会发生许多变化。在这篇文章中，我将主要从整体流程的角度来解释如何应对这些变化。

QA（质量保证）迄今为止所发挥的作用

首先，让我们了解一下 QA（质量保证）到目前为止扮演了什么角色。下面是许多人都熟悉的软件开发流程图。这是一个非常简单的表达，在实际应用中，还可以根据需要进一步细分或者配置成更复杂的形式。

这里需要注意的一点是，QA活动通常等同于测试活动，并被定义为“QA步骤=测试步骤”，但正确的定义是“测试是QA活动之一”。 

在这个阶段，QA基本上执行功能和非功能测试以及手动测试。

如果支持 QA 功能，还可以应用探索性测试或自动化测试方法。当然，自动化测试并不总是比手动测试更好。一个合格的QA必须能够准确判断项目和产品的情况，并提出有效的测试计划。 

现在，为了将QA扩展到更广泛的含义，即QA（质量协助），我们来看看“左移”和“右移”两种方法以及应用示例。

左移方法

左移字面意思是“左移”QA 在开发过程中的角色。下图显示了缺陷发生的阶段以及纠正缺陷的成本。从这张图可以看出，许多缺陷是在编码阶段引入的，而且发现得越晚，修复它们的成本就越高。这更清楚地表明哪个背景应该向左移动。 

左移旨在尽快完成测试并尽早发现缺陷。单元测试、组件测试、API 测试和性能测试可以有效地及早发现缺陷，而实现这一点的关键要素是自动化测试。QA 通过自动化测试尽早参与开发阶段，以便在开发过程中实现持续测试。

这使得 QA 可以将其活动范围进一步向左扩展，如下所示：

左移方法不仅仅是从测试角度来看的一种方法。下图比较了左移模型和传统质量模型。 

在此图中我们应该注意的是，虽然开发和构建区域在左移模型中很重要，但规划和设计区域也同样重要。因此，从质量角度左移必须在开发阶段之后进一步左移，如下图所示：

QA 的作用现已扩展到规划阶段。我们终于可以谈论左移的真正含义了。将 QA 角色扩展到规划阶段并不意味着简单地检查规划规范。从商业角度来看，这意味着从一开始就审视项目的目的和方向，并在每个阶段验证产品的功能和设计。QA 必须能够通过参与规划阶段的重要决策来为项目和产品做出贡献，并在与开发团队密切合作的同时成为提高产品质量的催化剂。还应该尽早参与项目讨论，以便识别风险并主动减轻其在项目每个阶段的影响。 

LINE应用示例

那么我们如何才能真正将其应用到我们的工作中呢？在 LINE，我们首先在规划阶段改进了同行评审流程，让 QA 积极参与。在这种情况下，质量检查的作用不仅仅是检查规格。在重要决策时刻，需要能够从高质量的角度提出好问题。 

AS-IS：一种在规划阶段后参与的 QA 形式
TO-BE：一种从项目一开始就活跃的 QA 形式

在开发阶段，我们一起审查和设计测试，以提供可预测的测试并提高测试透明度。这使得开发人员能够了解他们的测试将来会如何进展，并允许他们在编码之前更加小心地处理丢失的情况和异常处理。

由于 QA 还可以更好地了解开发设计，因此他们可以确保测试用例的安全，从而大幅提高测试覆盖率。以下是我们在共享模块重构开发阶段与开发人员一起审查和设计的测试计划的一部分。 

在测试阶段，测试逐渐从小规模的单元测试发展到大规模的集成测试。小规模单元测试是开发人员最擅长的事情之一，也是所有自动化测试的基础。

在LINE的开发流程合规性中，开发人员负责编写这些测试。QA 按照本指南来验证开发人员编写的测试，建议开发人员以更高的质量意识编写单元测试。另外，在集成测试过程中，通过API测试、性能测试、UI自动化测试等自动化测试来实现持续测试。下面的仪表板显示了 LINE Keep 集成测试过程中执行的自动化性能测试的结果。 

上述大部分测试都是基于自动化测试进行的，但仅靠自动化测试无法处理大量的异常情况，也无法进行各种非功能测试。作为弥补这一点的方法，我们进行充分利用启发式方法的探索性测试。

探索性测试的目的是通过适当利用诸如配对审查、配对测试、测试记录和汇报等元素来发现缺陷。自动化测试是一个很棒的工具，但它本身不应该是目的。有时，你最终会浪费更多资源来维护自动化测试。为了避免陷入自动化陷阱，你应该始终考虑高效的自动化测试方法，并尝试平衡手动和自动化测试。以下是 LINE 进行的实际探索性测试的示例。 

然而，尽管有这些不同的尝试和努力，要提供更频繁、更高质量的服务仍然非常困难。这是因为无论左移方法有多好，它最终使用的测试数据都只存在于孤立的环境中。我们所做的一切最终都是为了用户的利益。因此，QA需要研究实时数据以更好地了解用户，另一种值得尝试的方法是右移。

右移方法

现在让我们向右扩展。右移是在生产环境中进行的测试活动。 

左移是一种提前测试的方法，但这并不意味着右移意味着你会推迟测试。这是因为，与Shift-left一样，Shift-right不仅仅指一种测试方法。右移方法收集现实环境中的用户反馈，分析该数据，并将其转化为指示需要改进的指南。通过在真实环境中执行测试，可以更多地关注非功能元素，而不是模拟环境。一些报告（例如下面的报告）已经表明许多人对生产环境中的测试感兴趣。

我们来比较一下左移和右移。 

左移	右移
接近预防行动	接近检测活动
在每个步骤中正确执行测试	以允许开发后用户反馈的方式进行测试
目标是尽早进行测试。	目标是确保核心功能在生产环境中正常运行。

那么在生产环境中执行测试需要哪些技能呢？它可以简单地定义为两件事：CX测试和分析技术。如果我们将其翻译成我们熟悉的术语或动作，可以表示为A/B测试、金丝雀测试、分阶段发布、性能测试等。最终，我们根据实际的用户行为和反馈来验证需求，并据此导出功能和性能测试场景，测试用户喜欢或不喜欢更改的程度，并检测各种环境中出现的缺陷。（通常这些测试基本上都是在人群测试Crowd test或集群测试Cluster test的形式）

LINE应用示例

那么我们如何才能真正将其应用到我们的工作中呢？在推出新功能或分析数据时，你需要 A/B 测试策略，因为仅内部测试是不够的。LINE 已经建立了各种类型的 A/B 测试策略。QA 必须对这些测试方法有足够的了解，并能够及时为项目提供建议。有必要明确组织A/B测试的原因和目的，以及之后要执行的行动项目，以确保在给定的资源内发挥最大的效果。以下是LINE提供的A/B测试指南。 

金丝雀发布是一种仅向特定受众分发和控制已实现功能的方法。代表性的方法包括服务配置（https://cloud.google.com/service-infrastructure/docs/glossary#config）、特征标记（https://www.atlassian.com/solutions/devops/integrations/feature-flags）等等，并且根据测试目的使用每种方法。下面是使用 Canary Release 的 LINE 示例。

这样，QA 可以在功能和非功能测试之后建议如何在生产环境中构建测试策略。例如，出于风险管理的目的，可以通过延长DFM（https://en.wikipedia.org/wiki/Eating_your_own_dog_food）等内部测试的周期来提高产品的稳定性。这些活动帮助我们检测发布后可能出现的意外问题。此外，可以通过分析用户模式、检查客户服务 (CS) 问题和分析应用商店评论等活动进一步加强开放监控。从这些活动中收集和分析的数据将用作项目的关键数据，并作为帮助创建更高质量产品的基础。

现在让我们再看一下软件开发过程。QA 现在可以将其质量活动范围扩展到发布和维护阶段。

超越质量协助的质量倡导者

这样，QA的角色就按照开发过程范式的变化从Quality Assurance转变为Quality Assistance，并且其作用在不断扩大，需要不断改变。如前所述，QA 活动影响所有流程，并且产品质量也根据QA能力的不同而有很大差异。随着 QA 角色的扩大，QA 现在与项目中各个职能部门的同事合作，包括自动化测试工程师、数据科学家、AI/ML工程师、CX设计师、DevOps工程师和SRE工程师。随着要覆盖的项目变得越来越大、越来越复杂，仅用一个QA支持所有与质量相关的任务已经达到了极限。

现在，QA（质量协助）必须更改为QA（质量倡导者）。我们不仅要在项目层面而且要在全公司层面成为质量的布道者和倡导者，努力营造一种全员关注质量、对自己负责的文化。这样的QA角色称为质量倡导者。 

你无法再自行“QA”一切，仅靠提高质量是不可能的。不要尝试自己做所有事情。即使这是一个测试，我们也需要一起做。通过共同协作，质量检查可以生产出比现在更高的质量。为了实现这一目标，质量倡导者必须不断向同事提出好的问题。你必须贡献新的想法来帮助你的同事提高质量。当然，这并不容易。不过我觉得这可以成为提升自己能力的动力。

我们应该继续这样做多久？矛盾的是，我相信“直到同事们达到高水平的意识并继续保持对质量的兴趣，即使没有质量保证”。我相信实现这一目标是理想的质量倡导者的角色。 

行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入群： 786229024，里面有各种测试开发资料和技术可以一起交流哦。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。