🕋 🤦🏿 🧓🏾 如何组织测试以加速和稳定产品发布。第2部分 🦋 👩🏾‍🚒 ♻️

测试人员有很多机会可以提高产品质量，并使团队工作更舒适。最主要的是与团队讨论任何更改，并仅实施对每个人都方便且有用的功能。

我叫Victoria Dezhkina，我负责在X5零售集团的大数据管理局中测试多种产品。在本文的最后一部分，我开始讨论如何更改产品团队“用于零售网络采购的自动化系统”中的流程。产品发布经常被推迟几天，并且常常是原始的。我们更改了代码计算和任务计划的顺序，这使我们可以将发布周期缩短几天，但是我们仍然必须制定出设置和接受任务的最佳格式，在发布周期中建立测试点，并学习如何确定问题的优先级以修复缺陷。

制定和接受任务与缺陷的格式

设置任务的方法在很大程度上决定了完成任务的速度和正确程度。您可以用不同的方式描述任务，例如，使用反映系统最终用户需求的用户案例。听起来像是这样：“用户希望通过按绿色按钮来接收报告。”

这种方法的缺点是它不能解释该决定的“幕后”。用户故事给开发人员留下了太多的自由，有时这会成为一个问题：团队开始重新发明轮子或看到有些费力的事情。考虑到在快速开发的情况下，几乎没有足够的时间来完成完整的文档，采用这种方法，您将获得使许多新开发人员集成到产品中的加密代码。

我们讨论了针对任务和缺陷的几种设计选项，并确定了“混合”方法：用例+技术子任务。商业客户编写用例，即描述使用新功能的选项，在此基础上，具有测试人员的分析师在技术上是开发人员的子任务。在Jira中的任务描述中，我们添加了用于创建任务的用例，或者允许您重现错误的测试用例，而主要任务的名称和描述仍然“易于阅读”。

例如，让我们看一下缺陷名称为“用户不理解选择购买率时如何发生的错误”的内容。任务说明包含：

您可以重现该错误的情况；
实际和预期结果；
后端和前端的子任务，并为开发人员提供明确的修复说明。“后端：对于此API，为前端提供相应的答案” +选项矩阵，显示每种可能情况下的答案。“前端：对于此API，根据后端的响应，发出相应的错误文本” +选项矩阵。

当开发人员完成子任务时，他只是将其关闭。如果所有子任务都已关闭，则缺陷将返回以重新测试。如果检测到其他问题，则会再次创建相应的子任务。

获得了相应的缺陷描述规则：

创建一个任务，其中描述了功能性问题，重现错误的情况以及到历史的链接，在此过程中发现了缺陷。
. : , , API , use case . , , API, , , , , , .

我们还拒绝在产品上形成AC（接受标准），因为在计划阶段，我们不仅讨论我们正在开发和测试的内容，还讨论了如何进行测试。

它给了什么？这种方法使我们可以随时了解用户方面的功能出了什么问题，在缺陷的哪个阶段进行工作，并根据前后的负载，以不同的方式将子任务优先处理相同的缺陷。

结果，甚至在开发开始之前，整个团队就了解每个任务的哪一部分会亲自影响到它，最后，每个任务都包含以下信息：如何开发，如何测试，是否有文档以及在开发过程中对其进行了更正。

该方法仅在我们的产品上使用，因为它对我们来说是最方便的。 X5大数据管理中心的其他产品使用它们自己的方案：例如，带有AC的用户案例。

看来，我们的选择根本没有帮助加速开发，因为它需要更多的步骤才能开始。但是事实并非如此。

我们组织了整个过程，因此测试与开发同时进行。因此，开发人员不会在测试人员进行工作并尽可能地本地化任务时保持闲置。另外，我们总是看到哪个特定的开发人员在完成任务，如何实现它-这使我们能够了解将来哪些开发人员将更快地解决新的类似问题。逻辑很简单：开发人员执行与编写代码没有直接关系的事情的次数越少，缺陷的定位就越好，越准确，就可以更深入地思考由特定错误引起的可能的连接和问题。

还可能出现一个问题，即我们在产品中建立的规则是否不会干扰部门中统一测试和开发标准的形成。实际上不是：部门的一般规则决定了在开发的某个特定阶段应包含的任务，而我们遵守这些要求，我们只是在早期阶段就完成了任务。

测试时刻

我们讨论了在什么阶段进行测试的问题很长时间。最初有一种检查本地分支中每个任务的想法，但是使用这种方法将无法检查这些任务如何协同工作，并且只有在组装发布的阶段才可以揭示它们的冲突，而现在更改任何内容都为时已晚。

因此，我们同意在一个测试台上分别测试每个任务。最初，我们想一次实施多个任务，但上面我已经告诉过您这个想法带来的风险。一次更快。这是一个已知的效果：减少并行任务的数量不会减慢速度，反而会加速过程。例如，在看板中，存在WIP限制（WIP正在进行中）之类的东西，它限制了每个角色可以同时解决的任务数量。

因此，我们建立了五个点，测试人员积极参与了开发过程：

在文档编制阶段。我们确保不存在与已经完成的逻辑冲突的问题；我们确定每个任务的实现细节。
在确定问题的阶段。我们与分析人员讨论与任务相关的所有可能情况，并在制定任务时将它们考虑在内
在计划阶段。我们讨论计划的实现如何与相关功能挂钩，以及带来什么问题。我们与产品协调所有关键缺陷并补充冲刺。
在准备发布。我们迭代地在测试平台上检查每个任务，在计划发布的前一天，我们将所有任务收集在一起并在一个平台上进行检查。
发布后。我们检查发行版在产品上的工作方式。

一开始，当我们每两周发布一次时，工作方案如下所示：

它变成了（每周发布一次）：

后端交互的规则-测试-前端连接

当在API的后端和前端之间发送大量不同的数据时，并不总是很清楚为什么需要它们以及它们如何交互。因此，前端可能会发生故障。例如，计算编号需求校准从背面传送。名义上，这是一个参数，但是应该“吸引”另外八个字段来支持计算。如果您不将它们与成本核算编号一起传递，则不会在前端执行此操作。

为避免这种情况，我们开始描述传递的参数，并在对Jira中用于开发API的子任务的注释中指出这些参数，该参数解释了后端和前端将交换哪些数据。我们试图描述Swagger框架中的所有API，但是在自动生成文档时，借助它的帮助，无法传递前端，后端将对传递的参数进行确切的操作。因此，我们同意，如果我们要讨论的不仅是背面写的参数，而是使用其他参数的参数，则有必要在任务中描述其目的。

我们还开始控制变量的指定，以便在同一API中将所有字段标准化。我们的产品包含微服务，每个微服务都可以具有自己的字段名称。在一个带有供应商名称的字段中可以是供应商，在另一个字段中可以是SupplierID，也可以是第三名，等等。将这些数据传输到前端的一个组件时，可能会遇到困难，因此我们遍历了所有参数并开始标准化所有变量名。为此，我们收集了所有当前名称的摘要表，所有前端组件及其使用的变量的表（前端开发人员提供了很大帮助）并进行了比较。现在，所有新API均获得标准变量名，并且在完成任务时会更正旧API。

加快缺陷修复

在设置任务的阶段，业务客户确定优先级-他最清楚产品开发所需的内容和顺序。但是，在向开发人员推广之后，当有修复缺陷的任务时，测试人员会确定其优先级。

有时有必要紧急更改这些任务的优先级-例如，我们发现后端存在一个小缺陷，如果没有这些缺陷，前端团队将无法开始修复。

以前，在这种情况下，我们立即去找开发人员，要求他们更改任务的优先级，但这分散了他们的注意力。因此，我们同意只在特定时间与您联系-代码冻结后，每天最多可以联系5次。它给了什么？我们不再通过突然打电话来降低开发人员的生产力，避免了停机时间，并增加了分析师完成任务的时间。

而且，由于任务不再对开发人员自发出现，因此我们始终知道谁承担了什么样的负载，谁曾经处理任务并且能够更快地处理它。因此，我们将更好地了解我们是否将按计划准备发布。

这些措施以及在开发，发布和生产中推出代码的统一逻辑允许将缺陷校正的时间从3天减少到3-4小时。

结果

在我们的采购自动化产品的9个月的工作中，我们设法将发布周期从2.5周缩短到1周，并有可能每天推出，从而大大提高了发布的稳定性。

发生了什么变化：

我们摆脱了开发后纠正缺陷的需要，因为我们将这项工作带到了最大程度地准备任务的阶段。
缺陷校正的时间从3天减少到3-4小时。
我们有机会“按需”发布版本。现在，我们可以收拾行李，展开任务，到晚上，一切准备就绪并进行调试。
我们为流程中的所有参与者提高了流程的透明度：现在，团队的所有开发人员和测试人员都了解当前正在发生的事情，忙于哪些任务，需要多少时间来开发和修复错误等。

奖励：可以减轻团队的压力（我希望），并且由于团队的协调工作（感谢交付），我可以轻松地进行远程操作：-)实施

这些改进，我们遵循以下几条规则：

测试人员和开发人员在同一条船上（重复一遍口头禅！），所以测试人员要做的第一件事就是与团队相处并找出最让她担心的地方，并寻求支持。我在团队中的盟友和合作伙伴是发行经理和开发人员。
没有现成的理想解决方案，需要寻求它。测试人员不会将规则强加于任何人，他会适应团队并随之改变自己的方法，同时牢记美好未来的形象，并温和地介绍实现这一目标的措施。
过于严格的限制和标准化不是一种方法。如果您做得过多，团队可能会失去灵活性。

帮助我们加快该产品开发速度的交互规则不能以纯粹的形式转移到该局的其他产品中-它们的排列方式不同，并且那里开发人员的需求也不同。但是创建这些规则的原理是相同的：确定代码计算的顺序，找到测试的最佳点，记录代码和API。

在产品内部工作的同时，我们正在开发旨在促进产品之间交互的规则，我们将在以下材料中对此进行说明。因此，在大数据管理局中，逐渐形成了开发产品质量的策略。

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

制定和接受任务与缺陷的格式

测试时刻

后端交互的规则-测试-前端连接

加快缺陷修复

结果

More articles: