提高生产力：实施新的 QA 角色以加快发布速度的指南

你好呀！

我很高兴与大家分享我如何通过实施系统 QA 角色将发布流程提高 20%。

鉴于我的公司是一家典型的产品公司，团队不是按产品划分，而是按组件划分。正因为如此，一方面，我们成功地组建了拥有知识“持有者”的强大团队。但另一方面，单位内的角色相对孤立，不同的硬技能和专业知识也带来了局限性。例如，我有时需要将测试人员从后端团队调到前端，反之亦然。

这导致了 QA 团队内部有效协调和跨团队交互管理的问题。当然，这最终影响了发布流程。

变更前发布流程

在更改之前，我们的发布流程如下所示：

1. 业务需求规范 (BRS)是概述企业内特定功能、系统、产品或项目的详细需求、期望和规范的文档。它充当业务利益相关者与开发或实施团队之间的桥梁，确保清楚地了解要实现的目标以及它如何与总体业务目标保持一致。它应该包含描述用户如何与功能交互的详细场景。功能所有者 (FO) 的职责是制定业务需求。
2. 软件需求规范 (SRS)是一份综合文档，概述了软件系统预期完成的任务的详细描述。例如，如何交互以及哪些命令交互、通过哪种协议以及将传输哪些数据。如果开发该功能的团队使用图形界面，SRS 应包括正在开发的功能的布局。功能架构师负责编写SRS。
3. 质量行动计划 (QAP) – 功能所有者在接受功能之前检查的一组案例。文档描述完毕后，我们就开始实现该功能。当第一个团队完成其部分功能的开发和测试后，它就会转移到第二个团队。第二个团队执行集成/开发/测试并将其传递给下一个单元。依此类推，直到所有参与功能开发的组件团队都经过这个流程。 FO 验证该功能，并将其发送到发布版本。

发布流程问题

所以，一切似乎都很好——文件、申请、验收案例。但在这个过程中我们遇到了以下困难：

QA 方面的问题：

• 需求测试仅在开发后开始。开发人员已经实施的任务及其要求将移交给 QA 团队。但是，正如我们所知，要求中可能存在错误。
• 找到对错误负责的团队需要相当多的时间，因为并不总是清楚哪些案例已经被其他团队测试过。
• 不重复使用测试工件。作为测试一项功能的一部分，QA 团队准备类似的测试数据集。但由于团队的孤立性和专业性狭窄，他们无法互相传输这些数据。

FO方面的问题：

• 由于功能较多，编写QAP需要花费大量时间。
• 所有团队开发后都会对功能进行验证。在我们的例子中，由于许多集成问题，这显着延长了发布流程。
• 由于产品的复杂性和团队之间的集成量，测试环境的准备也很精确。不同的团队同时测试他们的组件，增加了混合、更改或删除数据的风险。

更新的发布流程中的系统 QA

为了促进 QA 团队之间有效的跨团队交互并减少发布流程，我们引入了系统 QA 的角色。

这有助于减轻使用 FO 编写验收案例的工作量，加快测试场景的编写速度，在将功能组件传递给下一个团队之前引入中间测试，并转移准备测试的耗时工作环境到系统 QA，考虑到团队对集成和测试数据的所有细微差别和要求。

系统 QA 已成为每个功能的技术和业务需求与整个产品之间的纽带。

系统 QA 入职

要了解整个发布周期，系统 QA 需要了解每个团队中特定发布周期的工作方式。入职通常持续大约三个月，因为系统 QA 在每个团队中花费 2-3 周的时间，了解他们的具体发布周期。

新流程的结果

• 我们现在正在测试功能所有者和架构师的 BRS/SRS 要求。及早发现错误可以节省企业成本。

• 我们建立了一个跨团队的 QA 空间，其中测试工件附加到每个功能 - 业务需求、技术要求、验收案例、其他团队的案例、测试数据。这极大地帮助所有 QA 团队处于单一环境中并有效地重用数据。

• 加速了错误本地化的过程，因为系统 QA 拥有来自所有团队的测试用例集。

• 由于系统 QA 正在为每个团队编写验收案例，因此这是加快和提高测试质量的极好提示。

• 由于每个命令后都通过验收案例验证该功能，因此集成过程变得轻松。

• 消除了 FO 的大部分负载后，功能的接受以及测试数据集成台的准备工作都加快了。

  
  

总体而言，将发布流程加快了 15-20%，并将集成错误数量减少了近一半，因为现在我们在编写 BRS 和 SRS 需求的阶段以及在功能开发框架内的团队集成期间都捕获了这些错误。

快乐而富有成效的测试！