如何仅用 6 名质量工程师每天发布 100 个版本

国内的互联网/it环境、工作模式大家都很熟悉，如果我们将眼光投远一点，看看大洋对岸的硅谷的公司都是如果有用少量的质量保障人员完成多个版本发布的。

今天，我们以美国最大的家具电商公司——Wayfair 为例，看看他们如何做的。

在线零售市场竞争非常激烈且要求很高，因此需要尽快将新特性和功能交付给客户——浪费的每一分钟都可能损失数千美元。

为方便叙述，下文的他们都改为“我们”

在 Wayfair，我们拥有数十种不同的内部和外部工具和应用程序，以及一百多个支持它们的团队。我们每天数百次将代码投入生产，对产品质量充满信心。Wayfair 目录工程团队拥有六名质量工程师 (QE) 和 200 多名开发人员。

我们从功能生命周期的最初开始。产品经理提出了一个新功能的想法并与团队分享，然后开始测试。

1、分析需求

修复测试阶段发现的错误的成本可能是修复需求阶段或设计阶段发现的错误的成本的十五倍。我们的团队中没有业务分析师，而且大多数团队没有专门的 QA/QE 资源。我们专注于预防错误，而不是在实施过程中发现错误。

我们培训团队在需求分析期间要寻找什么，并分享最佳实践，以确保每个人都在同一页面上（验收测试驱动开发、行为驱动开发）。通过与主要利益相关者之间的对话和协作，我们发现了所提议功能的价值并构建了正确的软件。

QE 教育团队如何在适用的情况下以 BDD 风格编写验收标准，以及如何分析完整性、正确性、一致性、清晰度和可测试性要求。

我们使用静态代码分析、漏洞扫描程序和代码审查

“质量不是来自检查，而是来自生产过程的改进。”——W. Edwards Deming

质量不是事后才考虑的问题，它必须超越产品本身。我们不能在发布时或发布后添加质量，也不能在产品中检查质量。这就是为什么我们部门大量投资于帮助我们预防缺陷或至少在流程中尽早发现问题的工具和流程。

我们积极使用工具和平台来持续检查代码质量，通过静态代码分析执行自动审查，以检测错误、代码异味和安全漏洞。这些方法有助于我们捕获棘手的错误、防止未定义的行为（影响最终用户）、修复危害我们应用程序的漏洞，并确保我们的代码库干净且易于维护，同时将技术债务降至最低。我们的代码审查流程可帮助开发人员学习代码库，并帮助他们学习新技术和技巧，从而提高他们的技能并提高他们编写的代码质量。

2、编写单元测试 

我们花在阅读代码上的时间和精力比编写代码多十倍，因为要编写新代码，你必须了解旧代码的作用。

单元测试帮助我们为开发人员提供了一种生成自文档化代码的机制，提高了软件的质量，并尽早发现问题。我们培养了一种在冲刺中为新功能编写单元测试并将其作为完成定义一部分的文化。我们为新增功能的单元测试覆盖范围设置了质量门槛，以直观地展示我们在扩大覆盖范围方面的进展。

3、只自动化最重要的事情

在 Wayfair，我们注意区分自动化测试和测试自动化。自动化测试只是帮助您避免手动测试的脚本，而测试自动化是关于我们如何编写和应用测试，这是软件开发生命周期 (SDLC) 的关键要素。

我们专注于隔离单元测试和隔离组件集成测试。GUI 和集成测试速度较慢，并且不会给设计带来压力。编写和维护成本高昂，而且也很脆弱。

4、提供有关测试或自动化的内容、原因和方法的培训和指导

人们不擅长测试自己的代码。需要一双全新的眼睛来确保代码运行良好，不会遗漏任何缺陷。对于 Catalog Quality Engineering 中的大多数团队，我们都有一个流程，开发人员会交叉检查队友实现的功能。如果您不擅长“手动测试”，那么您将永远不会在测试自动化中取得成功。如果
您自动化“垃圾”，那么它就只是自动化的“垃圾”。团队必须接受培训或至少配备有关测试什么、如何测试、自动化什么以及如何自动化的文档。Catalog Quality Engineering 团队会培训测试自动化和一般测试，使开发团队能够拥有自己的质量。

5、可视化产品健康状况和测试自动化

我们从开发和生产环境中获取、汇总和分析自动化测试结果和指标（代码覆盖率、通过率、性能指标等），以直观地了解产品的健康状况。根据这些数据，我们创建了带有精美图表和图形的仪表板，并将其显示在办公室各处的电视上，让每个人都能参与到完善产品质量的活动中。

6、通过部署管道实现持续交付

如果没有适当地集成到交付流程中，自动化测试几乎毫无用处。我们为所有工具设计和构建 CI/CD 管道，以便能够以最少的手动操作向客户提供新功能。

我们拥有一个基础设施，使我们能够逐一交付功能。我们可以在早上开始开发功能，并在当天将其发布到生产中，并且对质量充满信心。

7、大多数测试都在隔离环境中运行

由于支持如此多的团队和应用程序，几乎不可能拥有一个稳定的开发环境来进行全面的测试。我们构建了一些工具，允许我们在自己的共享服务实例中本地运行测试，这样我们就可以以任何我们想要的方式操作数据，并对环境和测试的稳定性充满信心。我再怎么强调也不为过：测试要么值得信赖，要么毫无用处。

8、对“大”功能采用增量发布的方式

向数百万客户推出新工具或新功能可能是一项冒险的事业。幸运的是，我们拥有可以帮助我们降低风险的工具和技术：

• 我们使用功能切换来轻松地在生产中打开或关闭功能，或使功能仅在 Wayfair 内部网络上可用。

• 我们使用供应商切换功能，以便我们能够为想要帮助我们改进工具的供应商启用一项功能。我们的供应商渴望尝试能够提高销量的新工具和功能，因此他们很乐意参与某些功能的 Beta 测试，并为我们提供宝贵的反馈。 

• Wayfair 帮助世界各地的人们找到最适合自己家居的物品。我们可以利用这种地理多样性，例如，先向欧洲受众发布一项功能，然后根据结果向北美受众发布（或反之亦然）。我们可以通过使用部署级控件（服务器）来实现这一点。

• 我们进行 A/B 测试。我们将一个版本的功能提供给一组用户，将另一个版本的功能提供给另一组用户。然后我们测量性能差异并收集反馈。


9、不断监控生产中的应用程序 

缓慢且“漏洞百出”的网站页面可能会带来高昂的成本，并且会给客户带来糟糕的体验。我们始终关注应用程序的关键指标，例如使用情况、性能、系统运行状况、错误等。如果我们向客户发布“重大”产品，这一点就更为重要。我们还与支持团队密切沟通，以更快地收集反馈和投诉。

10、如果出现问题，回滚更改

我们拥有可让我们轻松回滚部署或在功能级别关闭代码的基础设施，因此如果在部署后发现影响重大的缺陷，我们可以轻松删除或“隐藏”功能。这可以通过使用功能切换、回滚更改或在几秒钟内提供修补程序来实现。

为了在将代码交付给客户时保持紧迫感而进行优化，这会增加我们偶尔发布错误的风险。我们接受这种风险，平衡其与正在开发的系统的重要性，并在下一个计划版本中修复已发布的错误。

最后要说的是——我们不是一天之内就过渡到目前的团队结构（Scrum 团队中没有嵌入质量工程师）的。首先，我们必须让团队成员接受测试（以一种好的方式），受到相邻团队的优秀榜样的启发，并参与测试自动化过程。只有这样，我们才能培养出整个团队对测试自动化和总体质量负责的文化。

现在，我们通过构建测试工具、定义标准和最佳实践以及对团队进行测试自动化培训，使目录工程中的自主团队能够快速、重复、可靠地交付价值。

欢迎扫码关注公号，讨论交流~