当我们无法控制测试软件时，如何用敏捷方法管理测试自动化项目？

Question

一个团队正在开发软件，并使用虚拟后端对其进行测试。该团队不允许访问用于测试(政治)的真实系统，所以我的团队正在用真正的后端来测试它。我们的团队与开发软件的团队没有任何关系。

我们得到了用户故事，它是在最后的sprint上实现的，我们得到了软件。我们是外部测试人员，而不是敏捷团队的成员。然后我们将测试用例自动化。现在，产品负责人希望我们用敏捷方法实现测试用例的自动化。

根据Product，规范团队将以用户story的形式为我们提供测试用例(产品负责人不知道是谁编写测试用例)，我们必须为该用户故事提供多少故事点。以前有人像这样工作过吗？

假设我们的sprint今天结束了，我们自动化了回归部分，但是明天我们得到了新版本的软件。如果有UI或任何其他更改，我们的测试用例可能无法在新版本中工作。这意味着我们必须在即将到来的sprint中更新我们的测试用例，等待我们的下一个sprint结束，产品负责人对它进行审查并接受它，然后我们才能运行测试。结果已经晚了。

我们怎样才能让这种情况发生呢？对于在使用敏捷方法自动化测试用例方面有经验但不是开发该软件的敏捷团队成员的人，任何提示都将不胜感激。

Answer 1

这里没有一个“正确”的答案，但是您的团队可以做一些事情来处理这种情况。我将假设您在评估和冲刺周期方面没有问题，您主要关心的是，当您正在测试的软件更改破坏现有测试时，您不希望被阻止。

• 保留一个维护缓冲区--这可能是处理问题的最简单方法。根据您认为需要多长时间处理回归问题，在sprint中留下一个缓冲区用于维护，以更新自动化和测试用例以处理更改。如果你不知道还剩下多少钱，我建议从你团队能力的1/4的缓冲开始，并根据你的需要进行上下调整。
• 总是有一个维护用户故事--如果您需要记录所有的活动，下一步就是有一个维护用户故事，您可以将其大小调整到团队容量的1/4左右，以涵盖您需要考虑的任何回归问题。
• 阻止新的项目-这将是我的首选。如果更改影响到现有的自动化，请阻止任何新的项目，直到更改(技术上是回归问题)得到解决为止。如果您必须证明您的行为是正确的，请指出，当您有失败的测试用例时，它们可能掩盖了更严重的事情，因此修复这些问题比添加新的测试更重要。
  • 使新项目依赖于修复失败的测试--如果可能的话，您应该将新测试视为依赖于正在修复的失败测试(以及开发团队发现的任何错误)。
  • 调整sprint项--如果修复/问题导致sprint溢出，请将新的测试移出，以便进行修复。

在决定使用哪种方法之前，我建议与您的领导或经理讨论哪种方法最适合您的团队和项目。敏捷过程的关键方面是，您可以适应变化并根据需要进行调整，包括在sprint中进行调整。

我建议您在计划sprint之前针对新版本的软件运行现有的测试自动化，这样您就可以知道是否需要包括工作以适应变化。

最重要的是，请记住，您正在做的最重要的事情是您正在测试的软件的自动回归。其他一切都可以而且应该是次要的，以保持您的回归测试套件的良好状态。

Answer 2

这里主要要了解的是，这里没有银弹。你有一大堆不同的问题要解决。我建议你安排一次会议，讨论以下几点。

• 我们的团队与开发软件的团队没有任何关系。嗯，这是个问题。请多解释一下为什么不可以。为什么不能改变呢？
• “我们得到了用户故事”。那是指挥和控制语言。你为什么不提前为这个故事做贡献呢？与测试人员10分钟的对话可以节省一周的开发时间，与开发团队的10分钟对话也可以节省一周的时间来测试错误的东西。
• “产品负责人不知道是谁编写了测试用例”。我是认真的?你想听听建议吗？拜托，你已经知道这太荒谬了。请在与他们的谈话中更加勇敢。
• “如果有UI或任何其他更改，我们的测试用例可能无法在新版本中工作。”什么？当事情发生变化时，你就不在圈子里了。这是功能失调吗？嗯，是的
• 是谁做的测试？让开发人员能够运行您的测试，并在由于开发更改而中断测试时帮助维护它们。如果开发人员不得不自己运行通过测试，他们就不能传递坏的代码。

对于我来说，如果另一个团队编写软件部分并不重要，我只需要专注于：

• 作为团队的一员，我们会提前完成方法和高级意图，以及如何在编写一行代码之前测试所建议的解决方案。
• 安排与企业的会议，并讨论你有多喜欢自动化-但不参与‘预先’是一个重要的问题，他们需要解决，以提高效率……继续雇用你
• 在我的测试中使用敏捷实践，这样即使应用程序状态是固定的，我也用同行评审来编写高质量、可维护的自动化。

最终，如果企业说“事情就是这样的，请接受它并编写自动化”，然后说你想要创建一个基于行业良好实践的高质量解决方案。否则，你将在尊重你、你的团队和良好原则的地方工作。我的建议是，在这样一种听起来很糟糕的情况下，把它放在一边。这门语言需要做些工作，但我不会为你说的。这不是一件容易的事，而且需要很多的机智。

Answer 3

我们怎样才能让这种情况发生呢？

也许你做不到，你总是会落后，你会遇到你的团队无法解决的障碍，因为新的软件版本的变化。

现在，产品负责人希望我们用敏捷方法实现测试用例的自动化。

让你的团队成为敏捷的教练，让这个人和开发团队的教练沟通，找出一种对两个团队都有利的工作方式。

盲目地复制敏捷方法只会导致货物崇拜敏捷，听起来您的团队已经深陷其中了。

我有一些经验：

用敏捷方法自动化测试用例，但不是开发软件的敏捷团队的一部分

成为敏捷开发团队的一员！确保团队在每一次迭代中都交付工作和经过良好测试的软件。不添加测试作为后遗症。