在线零售市场竞争激烈,要求很高,因此您需要尽快向客户提供新的特性/功能。在这些现实中,每浪费一分钟都会让你损失数千美元。

在Wayfair,我们有几十种不同的工具/应用程序(内部和外部)以及一百多个支持它们的团队。我们对产品质量充满信心,每天发布数百次代码投入生产。在本文中,我将重点介绍Wayfair目录工程团队

在目录工程中,我们创建了一个灵活、可扩展和以用户为中心的市场平台。我们一直策划着世界上最大、最吸引人、购物最多的家居用品目录。我们高效地收集、转换和优化产品数据,为定义市场的消费者目录体验提供动力,以便消费者发现他们喜爱的产品。

这篇文章是关于测试的,所以,请,让我们见见目录质量,工程团队。

目录质量工程通过自动化和测试管道基础设施使目录工程团队在测试和开发策略方面具有卓越的能力。我们与许多Wayfair团队和工作组合作,以提高质量培训、工具和自动化框架。

让我们从特性生命周期的最开始开始开始我们的旅程,在这里,当产品经理(PM)提出新特性的想法并与团队共享时,测试就开始了。

我们分析需求

修复在测试阶段发现的bug的成本可能比修复在需求阶段或设计阶段发现的bug的成本高出15倍。我们训练团队在需求分析期间寻找什么,并分享最佳实践,以确保每个人都在同一页上(验收测试驱动开发、行为驱动开发)。通过关键利益相关者之间的对话和协作,我们发现了建议功能的价值,并构建了正确的软件。

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

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

“质量不是来自检验,而是来自生产工艺的改进。”

––W.Edwards Deming

质量不是事后才想到的。它必须超出产品的范围,我们不能在发布时或发布后添加它,也不能在产品中检查它。这就是为什么在我们的部门,我们在帮助我们防止缺陷或至少在过程中尽早发现问题的工具和过程上投入了大量资金。

我们积极使用工具和平台来持续检查代码质量,通过对代码的静态分析来执行自动审查,以检测bug、代码气味和安全漏洞。这些方法帮助我们捕获棘手的bug,防止未定义的行为(影响最终用户),修复危害我们应用程序的漏洞,并确保我们的代码库是干净的和可维护的,技术债务最少。

我们编写单元测试

单元测试帮助我们为开发人员提供了一种生成自文档代码的机制,为我们的软件提供了更高级别的质量,并在早期发现了问题。我们培养了一种为sprint中的新特性编写单元测试的文化,并将其作为Done定义的一部分。我们为新添加的功能设置了单元测试覆盖率的质量门,以可视化我们在扩展覆盖率方面的进展。

我们只把最重要的事情自动化

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

大多数团队都不会为新添加的特性(尤其是与GUI相关的功能)生成sprint测试自动化。这是有意的;我们在投资回报率高的地方实现自动化。

我们专注于独立单元测试和独立组件集成测试。GUI和集成测试很慢,它们不会给设计带来压力。它们的书写和维护成本很高,而且也很脆弱。由于支持如此多的团队和应用程序,要有一个稳定的开发环境来进行全面的测试是很复杂的。我们构建的工具允许我们在自己的共享服务实例中本地运行测试,这样我们就可以以任何方式操纵数据,并对环境和测试的稳定性充满信心。我怎么强调都不为过:测试要么是可信的,要么是无用的。

我们将产品的健康状况和测试自动化可视化

我们从开发和生产环境中获取、聚合和分析自动化测试结果和度量(代码覆盖率、通过率、性能度量等),以可视化产品的健康状况。基于这些数据,我们创建了具有奇特外观的图表和图形的仪表盘,并将其显示在办公室的电视上,让每个人都感觉自己在致力于完善我们的产品质量。

我们通过部署管道实现连续交付

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

我们有一个基础设施,使我们能够提供一个又一个功能。我们有可能在早上就开始开发功能,并在当天发布给生产部门,对质量充满信心。

我们对“大”功能使用增量卷展栏

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

  • 我们使用功能切换在生产中轻松打开或关闭功能,或使功能仅在Wayfair内部网络上可用。
  • 我们使用供应商切换因此,我们可以为一些希望为改进我们的工具做出贡献的供应商启用该功能。我们的供应商急于尝试新的工具和功能,使他们能够提高他们的销售,所以他们很高兴参加测试的一些功能,并向我们提供宝贵的反馈。
  • Wayfair帮助世界各地的人们为他们的家找到最好的物品。我们可以利用这种地理多样性,例如,先向欧洲观众发布一个功能,然后根据结果向北美观众发布(或者反过来)。我们可以用部署级别控件(服务器)。
  • 我们的行为A/B测试. 我们将该功能的一个版本提供给一组用户,另一个版本提供给另一组用户。然后我们衡量绩效差异并收集反馈。

我们不断监控我们在生产中的应用

缓慢和“错误”的网站页面可能是非常昂贵的,是一个糟糕的经验,为客户。我们始终关注应用程序的关键指标,如使用率、性能、系统健康状况、错误等。如果我们向客户发布一些“重要”的内容,这一点就显得尤为重要。我们还与支持团队密切沟通,以更快地收集反馈和投诉。

如果出现问题,我们将回滚更改

我们的基础设施允许我们在特性级别轻松回滚部署或关闭代码,因此,如果在部署之后发现了影响较大的缺陷,我们可以轻松地删除或“隐藏”特性。这可以通过使用上面讨论的特性切换、回滚更改或在几秒钟内提供修补程序来实现。

为了给客户提供代码的紧迫感而进行优化,必然会增加我们偶尔发布bug的风险。我们接受这种风险,将其与正在开发的系统的关键性相平衡,并在下一个计划的版本中修复已发布的故障。

最后一个音符:我们没有在一天内过渡到我们当前的团队结构(scrum团队中没有嵌入式质量工程师)。首先,我们必须让我们的团队成员受到测试感染(以一种好的方式),受到来自相邻团队的好榜样的启发,并参与测试自动化过程。只有这样,我们才能培养整个团队负责测试自动化和质量的文化。

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