永远跳过 QA 审批的 5 种方法！

3天的计划，5天的执行，然后整个工作就因为质量保证而停滞了数周。另一方面，如果问题被解决，就会导致测试工作不力，最终只能被动地进行应急处理。

这听起来熟悉吗？

好吧，至少我的团队在 Shuttl 开发时，开发人员挑选的每个新功能都是这样的。无论大小，QA 都是每次变更的瓶颈。

这是不可避免的，因为如果没有质量保证，质量风险就会更高。

没人喜欢总是忙于救火。那么，该如何解决呢？

在此博客中，我们将讨论 5 个步骤（按顺序），这些步骤将帮助您解除 QA 批准的阻碍：

1. 当 QA 介入时，左移
2. 你编码，你拥有
3. 总是在需要的时候支持
4. 回顾并寻找改进模式
5. 从行业基准中获取灵感

当 QA 介入时，左移

典型的开发过程从规划开始，然后进行编程、测试、发布并监控以防出现任何故障。（如下所示）

在一个典型的软件团队中，通常会有多名工程师负责开发功能，但每个团队（或小组）会配备一到两名手动 QA。一旦开发人员完成功能/错误修复，QA 负责进行系统测试以确保其正确性，然后发布。

当多个功能需要同时发布时，问题就出现了。
这时，QA 的精力就会被压垮，不得不在不同功能之间切换。
这时，即使开发团队已经有一个功能准备就绪，生产环境也会被推迟。

最棒的是：经过长时间的等待后，会有反馈，然后再次长时间等待 - 所以循环继续！

为了解决这个问题，第一步是将 QA 向左移动。

不要让他们手动测试更改，而是要求他们在功能规划期间创建测试计划

测试计划
一份包含产品应运行的所有场景、所有极端情况和涵盖的级联风险的文档。

由于 QA 是思考极端情况的专家，因此将他们从繁琐的测试中解放出来将提高测试用例的质量和覆盖率。

测试计划准备就绪后，我们将进入下一步⬇️

你编码，你拥有

我们开发人员完全有能力、非常聪明地把所有东西都端到端地运行起来。测试计划减轻了我们思考各种糟糕情况的负担，现在我们只需要检查、检查、再检查。

编程之前制定测试计划的好处之一是，您可以根据测试计划本身修复您的设计，从而节省许多时间（和夜晚）。

所以，现在没有什么可以阻止你了！

总是在需要的时候支持

然而，生活并非如此理想。有时你可能需要制作虚假数据、设置新环境或了解其他背景信息，而这可能会彻底打乱你的思路。

然后你必须记住 QA 是我们的队友😄并提前告知他们哪些测试计划项目可能需要他们的帮助，以便当你准备测试时，他们可以支持你激活这些活动。

让他们参与的常见方式：

• 在规划阶段标记项目本身
• 当你即将完成开发时，提前预约他们的时间来准备好你的环境
• 在单口相声中寻求他们的帮助

回顾并寻找改进模式

在这个转变过程中，肯定会出现不同阶段的问题：

• [变更前] 等待 QA 批准花费了大量时间
• [变革期间] 初期问题和流程调整，以适应团队的舒适度
• [变更后] 通过迭代来寻找可以改进的地方，以实现团队的最高生产力。

一个总是能帮助你的做法是，在每次冲刺之后根据实际数据进行回顾（如下所示）

整理数据可能非常耗时，因此有破坏所有回顾的风险。

（免责声明：我也是联合创始人）像MiddlewareHQ这样的工具可以帮助您将所有流程洞察从 Jira、Git 等工具集中到一个地方，从而专注于您的工作。

当运动员（团队）训练时，可以将其视为整个团队的健身带🏃🏼‍♀️

从行业基准中获取灵感

作为软件工程师，我们从小就关注技术基准和语言基准。然而，在生产力方面，却没有统一的标准。

质量保证 (QA) 成为瓶颈是软件交付过程中的众多挑战之一。

我认为，持续改进的一个好方法是利用像你们这样的团队的行业基准。DORA 指标是 Google 的一个优秀框架，他们每年都会发布年度报告，其中包含交付流程和质量的基准。（了解更多关于 DORA 指标的信息）

这就是我们决定推出开源产品的目的，以便为您选择的环境中的任何团队测量 DORA 指标。

我们的使命是消除开发过程中的摩擦，让开发者能够更好地构建！如果您喜欢我们正在构建的内容，请考虑给我们一个⭐️！

祝一切顺利，希望没有什么能阻碍你实现目标！