如果没有完善的工作流程，当今的快速高效的软件开发是不可想象的：安装时每个组件都已转移到组件中，产品不会处于闲置状态。 两年前，我们与M.Video一起开始在零售商的开发过程中引入这种方法，而今天我们继续进行开发。 什么是小计？ 结果得到了充分的回报：由于实施了更改，因此可以将发行版的发布速度加快20-30％。 需要一些细节吗？ 欢迎来到我们的后台。

从Scrum到看板

首先，实现了方法上的更改-从Scrum（即sprint模型）过渡到看板。 以前，开发过程如下所示：



有一个开发分支，有五个团队的冲刺。 他们在自己的开发分支中编码，冲刺在同一天结束，并且所有团队都在同一天将其工作结果与主分支合并。 此后，将进行回归测试五天，然后将分支交给试点环境，然后再分支给生产环境。 但是，在开始进行回归测试之前，花了2-3天的时间来稳定主分支，消除与命令分支合并后的冲突。

看板的优势是什么？ 团队不等待冲刺结束，而是在完成任务后将其本地更改与master分支结合起来，每次检查碰撞冲突。 在指定的日期，与主机的所有关联都将被阻止，并开始进行回归测试。



结果，我们设法摆脱了术语向右的不断移动，回归
没有延迟，发布候选版本将按时交付。

无处不在的自动化

当然，仅仅改变方法是不够的。 第二步，我们与零售商一起进行自动化测试。 总共测试了约900个方案，并按优先级将其分为几组。

所谓的阻止者大约有100种。 即使在一场原子战中，他们也应该在该网站-M.Video在线商店上工作。 如果其中一种阻止程序不起作用，则说明该站点存在很大问题。 例如，阻止程序包括一种用于购买商品，应用折扣，授权，注册用户，下达信用订单等的机制。

大约还有300种情况至关重要。 例如，这些功能包括使用过滤器选择产品的能力。 如果此功能失效，即使目录中的购买和直接搜索机制有效，用户也不太可能购买商品。

其他情况是主要的和次要的。 如果他们不起作用，人们将获得使用该网站的负面经验。 这包括许多对用户的重要性和可见性不同的问题。 例如，布局（主要）消失了，没有显示股票的描述（未成年人），个人帐户（次要）中密码的自动建议不起作用，恢复（主要）不起作用。

与M.Video一起，我们在其余场景中将拦截器的测试自动化了95％，减少了约50％。 为什么大约一半没有自动化？ 原因有很多，也有不同。 在某些情况下，先验条件不适合自动化。 在复杂的集成案例中，需要进行手动操作才能进行准备工作，例如，在生产环境中致电银行并取消贷款申请，联系销售部门并取消订单。
回归测试的自动化减少了其持续时间。 但是，在每次将命令分支与master分支合并之后，我们就对阻止程序进行了进一步的自动化烟雾测试。

在使测试自动化之后，我们在完成与master分支的关联之后终于摆脱了延迟。

小黄瓜来营救

为了巩固成功，我们的团队亲自对测试进行了重新设计。 以前，这些表是：操作→预期结果→实际结果。 例如，我使用这样的用户名和密码登录到该站点； 预期结果：一切都井井有条； 实际结果还可以，我要转到其他页面。 这些都是麻烦的情况。

我们将它们翻译成Gherkin表示法，并自动化了一些步骤。 让我们在网站上获得相同的授权，现在脚本的格式如下：“ 作为该网站的用户，我使用授权数据登录，该过程成功完成了 。” 此外，“ 站点的用户 ”和“ 使用授权数据登录 ”在单独的表中列出。 现在，无论数据如何，我们都可以快速运行测试用例。

此步骤的价值是什么？ 假设有一位测试人员正在测试一个项目。 他不在乎如何编写测试，甚至可以以清单的形式进行检查：“检查授权，注册经过验证，购买通过卡进行验证，Yandex进行购买。金钱通过验证-我很帅”。 一个新来的人问：您是通过电子邮件还是通过Facebook登录？ 结果，清单变成了脚本。

该项目有五个团队，每个团队至少有两个测试人员。 以前，他们每个人都按自己的喜好编写测试，结果，测试只能由其作者支持。 使用自动化，一切都变得很乏味：要么需要聘请单独的自动化工程师，将整个测试动物园翻译成脚本语言，要么就把自动化视为一种现象。 Gherkin帮助改变了一切：在这种脚本语言的帮助下，我们创建了“多维数据集”-授权，购物篮，付款等，测试人员现在可以从中收集各种脚本。 当您需要创建一个新脚本时，一个人不必从头开始编写脚本，而只是以自动测试的形式提取必要的代码块。 Gherkin表示法已经培训了所有功能测试人员，现在他们可以独立地与自动化交互，支持脚本并解析结果。

我们并没有就此停止。

功能块

假设版本1是该站点上已经存在的功能。 在版本2中，我们希望对用户和业务场景进行一些更改，结果，部分测试由于功能更改而停止运行。

我们构建了测试存储系统的结构：将其划分为功能块，例如“个人帐户”，“购买”等。现在，当引入新的用户脚本时，必要的功能块会在其中打勾。

因此，与master分支结合后，开发人员不仅可以检查阻止程序的工作，还可以检查与所做更改所影响的主题区域有关的脚本。

第二个结果是，维护测试本身变得更加容易。 例如，如果您的个人帐户中发生了某些更改（下订单和交货），那么我们就不必晃动整个回归模型，因为更改后的功能块是立即可见的。 也就是说，使测试套件保持最新状态变得更快，因此更便宜。

看台的问题

在验收测试之前，没有人曾经测试过展位的性能。 例如，他们给了我们一些测试平台，我们对其进行了几个小时的回归测试。 他们跌倒，理解，修复并再次运行测试。 也就是说，我们在调试和重复运行上浪费了时间。

解决问题的方法很简单：他们总共编写了15个API测试来检查机架的配置，这些测试与功能无关。 测试与构建版本无关；它们仅检查对于传递脚本至关重要的所有集成点。

这有助于节省大量时间。 的确，在实现自动化之前，我们只有14位测试人员，检查工作繁琐冗长，几乎每天都有脚本，包括150个步骤。 在这里进行测试，在第30–40–110步的某个位置，您会发现支架无法正常工作。 我们将失去的工作时间乘以14人，感到震惊。 在引入了自动化和机架测试之后，我们设法将测试员的数量减少了一半，并消除了停机时间，这给总会计师带来了很多欢乐。

樱桃蛋糕

第一个问题是bugflow。 形式上，这是任何错误的生命周期，但实际上是任何实体的生命周期。 例如，我们在Jira中使用此概念。 另外一种状态使我们能够加快发布速度。

总的来说，过程看起来像这样：他们发现了一个事件，将其投入工作，完成了，将其移交给测试，进行了测试，然后将其关闭。



我们了解到缺陷已经消除，问题已经解决。 他们添加了另一个状态：“用于回归测试”。 这意味着在分析之后，将检测到严重错误的方案添加到900个方案的回归集中。 如果他们不在那里，或者他们的细节不足，那么我们会立即获得有关生产者或飞行员状态的反馈。



也就是说，我们知道存在问题，并且由于某种原因我们没有考虑到它。 现在，添加错误检查脚本可以节省大量时间。

我们还在测试级别引入了回顾。 看起来像这样：他们编辑了一个数位板“发行版号，其中的错误数量，阻止程序和其他脚本的数量以及解决方案的数量”。 同时，我们估算了无效决议的数量。 例如，如果您从40个bug中获得15个无效bug，那么这是一个非常糟糕的指标，测试人员不仅在浪费时间，而且在浪费开发这些bug的开发人员的时间。 伙计们开始思考并解决这个问题，介绍了由经验丰富的测试人员修改错误的程序，然后将其发送给开发人员。 他们做得很好。

因此，存在不断的反思并致力于提高质量。 分析产品中的所有错误：为每个错误创建一个测试，该测试立即包含在回归集中。 如果可能，此测试将自动执行并定期运行。

结果

最初，计划增加发布的频率并减少错误的数量，但是结果有些超出预期。 合理构造的自动化过程使得在短时间内增加自动化测试的数量成为可能，并且对遗漏的错误的分析使开发和测试团队能够优化脚本的优先级，并专注于最重要的脚本。

自动化结果：

• 最多4天（而不是之前的10天）减少了回归测试的持续时间；
• 手动测试团队减少了50％；
• 从30-35天减少到25天，上市时间缩短了-从功能进入团队的积压订单直到进入飞行员。

测试自动化团队，Jet信息系统