Get best of the week

如何组织测试以加速和稳定产品发布。第1部分

如果没有达成团队合作精神，则各个流程参与者和整个团队之间将不断发生冲突，并且同一产品内的公司产品或微服务将使用共同的资源和基础结构相互干扰。结果将是永久性故障，冲突和减速。在这种情况下无法实现快速且可预测的释放。

我的名字叫Victoria Dezhkina，我在大数据产品X5零售集团的开发和维护部门从事测试。我将告诉您我们如何更改一个产品团队中的测试过程，以将发行版本的准备工作加快将近一半，并减轻团队的压力。现在，我们将这种方法引入公司的其他产品中进行测试。



X5零售集团大数据管理局目前正在开发13种产品，其中4种是在货币化部门进行的，这些产品面向国外市场，并且任何错误（无论是产品缺陷还是过时发布的功能）都会产生经济影响并导致客户流失。实际上，这些是内部团队，它们在国外市场上赚钱，并遵守大公司中的小企业规则。

我们所有产品的目标都有很大差异，因此需要不同的开发和测试方法，但是它们有很多共同点：它们使用相同的基础结构（Kubernetes，Greenplum，测试服务器），并且来自不同产品团队的开发人员有时会互相替换假期。

在这种情况下，协议的作用急剧增加：如果团队中的一个成员不知道另一人正在做什么，并且每个团队都有自己的规则，那么不可避免地会出现问题。

例如，两种产品使用相同的负载测试基础结构，并且都迫切需要进行测试。由于没有相互通知，因此他们同时执行此操作，结果是得到错误的结果，这是因为DBMS已“放下”并且不清楚是谁。他们希望节省谈判时间，结果，他们浪费了很多时间而没有任何结果。
不排除数据丢失。假设其中一个产品占用了免费的测试服务器，而没有警告任何人。正式地，硬件被认为是免费的，因此另一种产品进入那里，并意外删除了第一个产品的所有测试数据。当然，这不是用户数据，而只是测试，但仍然是一个不愉快的情况。

如果工作没有事先计划，可能根本没有足够的工人。例如，现在在我们的首长级办公室以一种服务格式进行压力测试，也就是说，我们根据要求为团队选择合适的专家。如果有几支团队在没有事先警告的情况下，在一天内要求进行负载测试，则可能根本没有足够的测试人员。

在这种情况下，最简单的方法似乎是为所有产品建立统一的交互规则。但是问题是所有产品都不一样。其中一些是供内部用户使用的，即公司其他部门的专家，例如，用于定价或研究需求的服务。另一部分是为外部用户（例如，供应商）开发的。这些产品具有完全不同的架构逻辑和质量标准。

处于不同准备阶段的产品也不接受相同的方法：在产品测试思想的早期阶段，首要任务是了解用户的功能以及对公司安全性的威胁。当产品需要支持时，其他要求首先是：用户便利性，现有功能的稳定性，对缺陷的响应速度以及对公司安全策略的完全遵守。

这两个因素-在同一个领域内共同工作和独特的产品功能-为我们设定了任务：制定规则，使团队不互相干扰，但同时又不会束缚测试人员和开发人员的双手而且他们不会将不同产品的开发简化为一个模板，而是充分利用了敏捷和产品方法的所有优势。

我会说几句关于测试人员为何在创建产品团队交互标准方面发挥领导作用的原因。事实是，由于我们工作的细节，我们看到了整个产品，而开发人员通常只专注于一个小领域。我们是第一个注意到问题并提供解决方案的人，但是最终的解决方案是与开发人员一起制定的。

我们已经写了这种集体工作的进行方式：在初始阶段，我们必须从字面上构成一个字典，以免术语混淆。但这只是开始。接下来，我们必须就大量细微差别达成一致。

我将以我们的一种产品为例，这是如何发生的- 分销网络的采购自动化系统。其任务是确保从商店需要某种商品到收到商品为止的所有过程的操作。

我们的产品改变了哪些流程


当我们到达产品时，发布版本每2周发布一次，但是它们几乎总是迟到几天，发布日期始终意味着我们肯定会继续工作，直到最后一个版本，我们才能稳定现有版本。有必要改变一些东西。

重要的是要注意，变化是常见的原因。未经发起人，测试人员或开发人员本身的任何同意，都必须得到整个团队和强大盟友的同意。任何变更都需要由整个团队进行讨论，以便收集尽可能多的想法，而不会错过任何可能的风险。我们产品的交付和产品经理以及在我之前曾系统地从技术和产品两方面改进流程。进入团队后，我从测试方面检查了流程，然后我们共同考虑了一个商定的“变更策略”。第一点是代码布局的更改。

代码布局


计算过程是团队发展的主要“痛点”之一，这里存在很多不同的问题。例如，一个团队只有一个分支带有代码，并且纠错不止于此。或者有多个分支，但是功能重叠的任务可能会同时出现在测试环境中，结果，测试人员将无法定位缺陷或检查其中一项任务的缺陷所阻止的某些新功能。关于绝望的开发人员，他们认为在不警告他人的情况下快速修复产品上的小问题并不坏，我通常不会说什么。

为避免所有这些情况，我们需要确定分支和环境的数量，并同意将代码进行测试的过程。

最简单的方法是使用“干净”和“脏”代码将进程分为两个分支。但是我们必须满足许多条件：

  • « », « »
  • ,
  • .

我们花了2个小时讨论一种新的工作方案，然后得出以下结论：我们启动了三个分支，其中两个分支（发行版和主版本）将使用干净的代码。在“主版本”中是当前产品版本，在“发行版本”中-已准备好推出功能。在开发人员中，测试发生，这里是准备测试的任务，开发在本地进行。部署到每个分支机构均与测试人员达成协议。这就是：



从测试的角度来看，这给了我们什么：

  • 每个任务的测试时间分别减少了20％。如果新任务在没有警告的情况下推出了测试，则不再需要再次进行检查，新任务不会阻止对已完成任务的检查，并且加快了缺陷定位的时间。
  • 在计划发行版本的当天，未选中的1-2个任务而不是4个（即，检查它们的时间减半）。
  • 集成测试和发布候选测试的时间从6小时减少到2小时（包括重新测试在内）。
  • 在发布阶段发现的缺陷数量已经减少。以前，在第一个发行版中，我们发现了10个以上，但现在不超过4个。重新测试的时间减少了2个小时。
  • 有机会在测试的同时继续开发。

我们花在测试上的总时间减少了产品发布的时间，减少了8小时。与团队讨论新计划的时间只有2个小时-并节省了整个工作日的时间，过去通常每两周就用一次。不错？

但是问题仍然存在。

  • , .
  • - , , .
  • .
  • , .

底线：发布日我们继续徘徊。

我们又聚会了。通过改进开发流程并添加CI解决了部分问题：



我们将自动部署部署到所有环境的时间将近一个月，但这加快了将近2个工作日的时间。团队已经为此花了很长时间了，发行经理和开发人员自己都参与了这一工作，但是到目前为止，他们还没有实现两件事：使向所有环境的推广是统一的，同时保留版本控制。自动部署违反了“在任何给定时间，测试人员必须知道每种环境中存在的内容”测试的主要原则，或者拖延了未经许可而无法完成任务开发的开发人员。

这是一个难题。忽略第一个原理，而不是加快速度，您会大大降低发布和错误放气的任务的可预测性。例如，如果已经结合“清洁任务”对缺陷进行了纠正，那么在推出固定任务时，肯定会发现有缺陷的任务。因此，您将不得不等待相关任务的缺陷得到纠正，推迟发布日期，或者重新修复已经修复的缺陷。

自动推出不是一个人，您不会同意。因此，我们以另一种方式解决了剩余错误的问题-一种特殊的计划方法，然后添加另一个支架。

规划开发和测试


最初，在计划时，我和团队讨论了开发人员是否清楚任务，需要多长时间以及我们是否适合冲刺。测试人员估计测试将花费多长时间。

同时，我们根本没有讨论可能发生的错误：我们没有预先预见到它们，也没有将它们包括在可能的任务列表中。结果，在测试过程中发现这些案例时，将它们作为单独的任务添加，它们需要时间来解决并增加了发布量，有时在联合任务测试阶段仅在发布候选中发现它们，无限期推迟发布。我们聚集了三个人-测试人员，交付人员和产品，并考虑了一个新的交互方案。

现在，在开始开发之前，我们宣布所有可能的错误。我变成了一个无聊的学生，他在计划阶段问了所有的一切：“如果第三方服务中断，将会发生什么？”，“如果我们得到null而不是0？”，“如果我们没有获得所有数据怎么办？ “，”如果Pechenegs袭击了？”依此类推，但现在我们已经做好了一切准备。

我们还开始讨论如何执行此任务或该任务以及如何对其进行测试。这样可以减少主动性（例如，发明各种自行车），并使每个团队成员了解自己的同事在做什么。顺便说一句，这使我们可以放弃接受标准（AC）。

为了避免新格式的讨论变得过于繁琐，我们开始这样做的时间不是提前2周，而是提前了一周。

新的代码布局和任务调度只是第一步。在明天将发布的文章的下一部分中，我将详细讨论我们如何更改团队中的整个流程系列：

  • 设置和接受任务与缺陷的格式：他们将用户案例留给了“用例+技术任务”混合体，这对我们来说更加方便。
  • 测试时刻：在发布周期中设置了5个点，测试人员在此点上主动控制产品创建的过程。
  • “后端-测试-前端”连接的交互规则：我们开发了一种方案，使我们可以检查在后端和前端之间传输的所有数据。
  • 加快修复缺陷的工作：建立有关如何优先安排调试任务的规则，以免再次分散开发人员的注意力。

这些措施使我们可以将发布周期从2.5周缩短到1个。速度的提高似乎很小，但是主要的成就是我们的发布变得更加稳定和可预测-我们有机会“按需”推出发布：我们可以团结起来每天都可以推出任务，到晚上，一切都将准备就绪并进行调试。

More articles:


All Articles