资深老鸟讲述如何改造初创公司QA团队

大家好，我作为一名QA工程师，从事质量保证工作已经很多年了，但我决定去一个QA(Quality Assurance)团队架构不完善的环境中挑战自己，于去年9月加入Shippio（电商物流公司），担任QA manager。

加入公司后，我感受到了很多挑战，在半年左右的时间里，我致力于各种管理和改进。在这篇文章中，我将针对我在前三个月的挑战介绍两项改进措施。

加入公司后面临的挑战

1. QA的角色只是“测试”

一般来说，似乎有一部分人认为QA团队在服务的规划、设计、开发、测试、发布的整个过程中只负责 “测试”，QA团队是 “发布前的最后堡垒”。

一些QA专业人员在对待测试方面可能是被动的，因为他们认为这是一个下游过程。

当我加入公司时，已经有三名QA成员参与其中，要处理众多的大问题和日常工作，特别是进行 “测试”，是很有挑战性的。

此外，Shippio目前正在采用Scrum敏捷开发（见下图），这就要求团队在短时间内取得最大成果。

在我看来，过去Shippio的QA团队被要求进行 "发布前的最后堡垒 "的角色，并在短时间内取得最大的成果。

然而，我的观点与此不同。我认为，QA应该参与到上游过程中，以防止bug的发生，而不仅仅是发现它们。通过这样做，我们可以在短时间内取得最大的成果。因此，我认为有必要解决这个问题。

2. 不明确的工作流程

2-1. QA工作流程

现有的团队成员以前从未进行过Scrum开发，由于刚刚引入Scrum系统，他们处于试错的状态。因此，他们感到有以下问题:

● 没有具体的流程（做事的方式因人而异）；
● 对于Epics或重要的变化。QA参与了规格审查，但将所传达的内容直接转录到测试用例中；
● 对于现有的功能改进或小的修复。当一个QA任务产生时，工程师解释了规格，并直接转录到测试用例中；
● 确定测试观点的时间也很晚。

2-2. 发布的QA工作流程

发布的QA工作流程也不清楚，而且有很大问题：

● 开发新功能的测试环境不是基于最新的主分支，也不清楚是基于哪个分支，这使得在测试环境中无法进行集成测试。
● 由于无法在测试环境中进行集成测试，在Main stating（master，见下图）上进行Sanity检查的工作量很大。 这意味着，发现重大bug的风险很高。

● 完善性检查的标准并不明确。
● 因为我们不能在测试环境中进行集成测试，所以Sanity检查的工作量很大。
● 没有跟踪我们发布了哪些功能以及何时发布。

我是如何改进工作的

如前所述，我觉得QA只是在做测试员级别的工作，所以我首先明确了QA的角色。

1. 界定QA的角色

QA团队需要与相关团队一起工作，不断提供高质量的服务，换句话说，就是 “Create value for someone”。

因为团队活动的范围和结构可能会根据情况而改变，但 "Create value for someone "永远不会改变。

因此，为了确保QA团队的目标不会错位，我为Shippio的QA团队制定了一个政策，从而确保所有QA成员都能同心协力。

简而言之:每个成员都是一个领导者

每个成员都必须:

● 根据用户需求采取行动，寻求并做最好的方式来完成我们的角色。
● 促进团队提供更高质量的服务和流程。
● 有好的决定和行动，在质量和速度的适当平衡下及时完成工作，并为用户提供尽可能好的服务，这一点非常重要。

为了实现上述目标，每个成员都必须承担起责任。

换句话说，我认为所有成员都应该意识到他们是领导者，并应采取相应的行动。

2. 改进工作流程

2-1. QA工作流程

对于一个初创公司来说，拥有一个内部的QA团队是不寻常的。

如上所述，拥有一个内部QA团队的好处是，QA不仅可以更容易地进行测试，而且还可以从创建产品的早期过程中介入工作来提高质量。

此外，由于没有关于bug管理或缺失规范考虑的工作流程，我已经建议并采用了这样的工作流程。这使我们能够将任务可视化，谁应该做什么，并将这些信息用于记录，以便将来分析缺陷。

(1) 从上游承诺开始

● 与利益或工作相关者合作开展QA活动，不限制活动的阶段。
● 在开展活动时，从计划阶段就考虑到活动将无休止地进行下去。

现在，QA也可以对所有的红色部分做出承诺。

(2) 提出并实施必要的发布流程

● 测试环境
● bug跟踪和规范监督的管理
● 了解要发布的功能
● 理性检查

2-2. 用于发布的QA工作流程

为了解决开发新功能的测试环境不能与最新的母版同步的问题，我做了以下改进：

(1) 测试环境

向工程师们解释，开发新功能的测试环境必须是最新的母版。

● 在开发新功能时，确保在开始开发过程之前将最新的master拉到本地环境。
● 因此，在测试环境中进行集成测试成为可能，现在可以在测试环境中发现重大问题。

(2) bug管理和规范疏漏的管理

在测试期间，很难搜索过去的bug或关于规范疏漏的问题，因为所有关于它们的沟通都是通过Slack进行的。因此，我们引入了一个流程来管理它们。

● 建立bug管理和规范监督流程的管理准则
● 为每个利益相关者召开一个操作流程解释会议

因此，可视化谁应该做什么任务已经成为可能，并用于记录，以便将来进行故障分析。

(3) 了解将要发布的功能

QA的职责并不以进行测试而结束。我认为他们不仅应该在发布前承担责任，也应该在发布后承担责任。要做到这一点，重要的是要正确了解何时以及哪些功能将被发布。

● 利用Nortion的数据库，可视化并准确了解哪些功能需要发布。
● 这将使我们能够直观地了解在下面提到的“健全性检查”需要做什么。

(4) 健全性检查（Sanity Check）

一旦所有的功能都在测试环境中测试完成，所有要发布的新功能都会被合并到Main staging中，并接受健全性检查。通过明确在这个健全检查中需要检查的内容，我们旨在减少每个成员的健全检查之间的颗粒度差异，提高执行速度。

明确在健全性检查中要做什么:

● 检查每个新功能在合并到Staging后是否能正常工作。
● 验证可能影响现有功能的领域。

通过彻底实施上面第一天提到的，可以提高健全性检查的速度，过去需要一天的健全检查，现在可以在几个小时内完成。

最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取 【保证100%免费】

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！