Get best of the week

如何通过测试来提高敏捷团队​​的绩效

敏捷开发旨在以适当的频率快速交付新功能，以确保持续不断的变更。灵活的方法使团队可以保持较高的进度，但是由于这个原因，代码的质量和产品的稳定性通常会受到影响。如何解决这个问题而又不致使团队陷入严密的框架，又不丧失敏捷方法的优势？帮助来自测试人员。我的名字叫Denis Dubovoi，我是X5零售集团大数据管理局测试部门的负责人，在本文中，我将告诉您测试人员的出现是如何帮助改善我们开发人员的工作质量的。



通过测试制定规则


敏捷团队经常忽略质量。部分原因是传统测试方法无法适应“灵活”的情况，部分原因是速度优先于质量。敏捷团队的主要任务是快速实现业务客户所需的功能。在产品形成阶段，尤其是当产品的功能由反复试验确定，开发人员需要针对当前请求快速重建产品时，尤其如此。在这种情况下，团队通常会这样决定：我们做MVP /第一个工作版本/学习Zen以后，我们会打电话给测试人员，因为它根本不了解如何组织灵活的测试。结果通常是交付时间中断，演示错误以及更糟糕的是在PROM环境中。

在我们的案例中，情况非常相似：X5零售集团大数据产品开发部门已经成立了2年，起初，产品质量仅由开发人员自己维护-没有专门的质量检查专家角色，并且产品中的测试部门和第一位测试人员出现了仅在一年前，产品才开始生产。

如今，测试部门已经有15个人：团队中有11位测试人员陪同产品，两个人负责制定负载测试的方向，另外两个人负责测试自动化的方向。在许多产品团队中，测试人员已经成为重要变革的催化剂：他们的到来简化了开发过程并提高了发行稳定性。为此，我们根据以下方案将测试人员连接到已经工作的团队：

1.深入研究过程


在第一阶段，我们需要了解团队现在的工作方式，角色的分配方式以及信息的交换方式。测试人员开始以“质量控制”的形式帮助测试，同时评估团队的成熟度和团队中的流程-为此，存在一个小的成熟度“热图”，可以在下面看到一个示例。在它上面，您可以看到我们每个产品如何制定各种方向（开发，测试，DG，DevOps，支持）。


成熟度热图

测试人员与开发人员一起收集对过程成熟度的评估，评估团队使用的一组技术和方法实践。结果，我们可以从热图中看到可以改进的地方，例如在产品生命周期的每个阶段（原型，中试，工业），在哪些方面（例如在开发中开发单元测试的实践或在测试中自动进行API检查），都建议采用自己的一套实践。

2.我们提出改进建议




确定了团队的生活之后，您可以考虑改善团队工作的最初建议。在这里，我们遵循以下逻辑：测试人员不是负责特定领域的专门职能，我们是团队的一部分，可以影响整个过程。为了促进改进的开展，我们从以下基本内容开始：

  • . , : , , , .. , , ! ;)
  • (, user stories) . , , , , . « » : , pdf ? , !
  • Definition of Ready ( ) Definition of Done ( ) .
  • 我们修复了冲刺阶段和关键点之一-点“代码冻结”。

我们调查了测试之前的各个阶段，并对测试本身进行了一些介绍，但是还有一个技术部分负责维护测试台并使用测试数据，而工业部分则负责产品支持。测试人员在所有这些阶段都参与其中-我们试图培养T型专家，他们不仅可以看到整个生产过程，还可以看到他们的直接功能。

3.我们向团队负责人和利益相关者介绍我们的改进，重点是这些改进将解决哪些问题


如果您获得团队的支持，则该过程将更加容易。重要的是“出售”您的想法，以显示您提议的更改将带来的利润。例如，我们上面提到的验收标准对于分析师来说可能看起来像是一项额外的工作，但是当团队了解将节省多少时间时-从数小时到数天，这可能需要细化任务-使得改进变得容易得多。

在某些情况下，您可以通过产品的所有者行事。例如，产品缺乏监控（例如，技术，带有日志和精美图形的图表）并且没有时间进行配置，因为这不是产品任务。在这种情况下，您可以联系产品并确切说明其从监视中将获得什么好处（它不会立即变得更加稳定，但是问题定位的速度将会提高），并请他为此分配资源。
在产品团队工作标准化的同时，正在开发确保产品质量的测试方法，例如评估和准备所需数量的测试数据，开发测试模型，为将来的自动化形成点等。

团队总是有可能不接受建议的更改，无论您觉得它们有多合理。在每种情况下，都有必要制定自己的方法并寻找一种单独的说服方式。这些产品有很大的不同，在一种产品中起作用的方法在另一种产品中根本不起作用。

许多团队都相信自己能够自己组织工作，有时这是事实。在某些情况下，我们的参与归结为推荐验证的要点，然后团队在代码级别完美地实施了所有工作，我们就在附近，随时准备提供帮助。但更常见的情况是，事情发生的方式有所不同：我们的员工加入了团队，开发人员开玩笑地开始“哭”测试人员发现的缺陷，这使他们感到高兴，因为这些缺陷是在演示或工业发布之前发现的。

什么改变了


产品团队的变化有所不同，并且影响了流程的各个方面。在其中一个团队中，测试最初是一个瓶颈：这需要时间，而且并不是每个人都了解此阶段正在发生的事情。作为实验，我们将开发人员连接到正在运行的测试，结果他们可以体验测试人员的工作，甚至可以看到整个产品-例如，不是单独的报告功能，而是从产品中的用户授权以及进行业务操作到最终的整个过程-卸载报告。因此，我们加强了整个团队的参与，使测试过程透明化，并表明了此操作的重要性，并且上述做法已成为常规。

在另一个产品中，在我们的帮助下发布周期已经改变。最初，冲刺的结果安排在星期五下午进行测试，星期一产品已经到达客户手中。星期五的最后，只有星期一的开始用于测试和修复关键错误，因此，新版本经常“原始”发行，或者开发人员不得不在周末紧急修复错误。经过几次艰难的交付工作后，团队仍将冲刺的交付推迟到了星期三（没有缩短冲刺的时间，只是将日程安排了两天）。现在，团队有时间在轻松的氛围中检查并纠正交货。



最终的决定权（是否更改）仍留在团队中：由她负责产品及其输出，这就是为什么她为自己选择最方便的选择。我们工作的目标不是将我们的方法强加给程序员，而是提供有关可能的风险的最大信息，并提供适合该产品的改进措施。

过去一年，我们的测试部门设法做到了：

  • X5零售集团大数据部门的7个产品中进行了定期的功能测试，其中2个已在PROM中达到稳定版本，而没有提出批评。定期对3种产品进行负载测试。
  • 15 – 1 15 :-) !

    – ( , Agile), , , , , – .

更改总是很复杂，但是如果我们扎根于产品，更改是必需的。测试人员可以为确保产品质量做出重大贡献。
在接下来的文章中，我和我的同事将讨论我们如何测试特定产品，选择测试策略，工具（例如Allure Enterprise版，这是一种用于管理测试，报告甚至管理自动测试的便捷工具），以及如何在管道以及我们看到的开发选项（测试驱动开发，如果您考虑过，这只是可能的选择之一）。

More articles:


All Articles