我们获得了上次冲刺实施的用户故事，并获得了软件。我们是外部测试人员，不属于敏捷团队。然后，我们使测试用例自动化。现在，产品负责人希望我们使用敏捷方法自动化测试用例。
根据产品负责人，规范团队将为我们提供测试用例（产品负责人不知道谁编写测试用例）以用户故事的形式，我们必须说出该用户故事的故事点数。以前有没有人像这样工作过？
比方说，我们的冲刺今天结束，我们自动化了回归部分，但是明天我们得到了该软件的新版本。如果存在UI或其他任何更改，我们的测试用例可能无法在新版本中使用。这意味着我们必须在即将开始的sprint中更新测试用例，并等到下一个sprint结束并且产品负责人对其进行审查并接受之后，我们才能运行测试。结果已经太迟了。
如何使这种情况起作用？对于那些具有使用敏捷方法自动执行测试案例的经验的人的任何提示，但不属于开发该软件的敏捷团队的成员，将不胜感激。
#1 楼
这里没有唯一的“正确”答案，但是您的团队可以采取几种措施来应对这种情况。我将假设您在估算和冲刺周期方面没有问题，并且您主要担心的是，当您要测试的软件更改破坏现有测试时，您不想被阻止。 >留下维护缓冲区-这可能是处理问题的最简单方法。根据您认为需要回归问题的时间，您会在sprint中留出一个缓冲区以进行维护，以更新自动化和测试用例以处理更改。如果您不知道要剩下多少，我建议您先从大约1/4的团队容量的缓冲区开始，然后根据需要向上或向下进行调整。故事-如果需要记录所有活动，则下一步是拥有一个维护用户故事，您的故事大小应约为团队能力的1/4，以涵盖您需要解决的所有回归问题。
阻止新商品-这是我的首选。如果更改影响了您现有的自动化，请阻止所有新项目，直到考虑到更改（从技术上讲是回归问题）为止。如果必须证明自己的行动是正确的，请指出，当您遇到失败的测试用例时，它们可能掩盖了更严重的事情，因此，与添加新测试相比，解决这些问题具有更高的优先级。
使新项目依赖于修复失败的测试-如果可能，您应将新测试视为依赖于修复失败的测试（以及发现的任何错误）由开发团队确定）。
调整sprint项-如果修复程序/问题最终导致sprint溢出，请移出新的测试，以便进行修复。建议您在决定使用哪种方法之前，与您的负责人或经理进行讨论，以了解哪种方法最适合您的团队和项目。敏捷过程的关键方面是，您可以适应更改并根据需要进行调整，包括在sprint中。
我建议的一件事是，在计划冲刺之前，对新版本的软件运行现有的测试自动化-这样一来，您便会知道是否需要包括适应变化的工作。
首先，请记住，您正在处理的最重要的事情是对要测试的软件进行自动回归。其他一切都可以并且应该使您的回归测试套件保持良好状态。
评论
+1不错的答案，但是“保持回归测试套件的状态良好”不是最重要的事情吗？导致：“一切都应保持回归测试套件的良好状态。”您的自动化测试将需要不断更新，以确保轻松，平滑地进行更新是您的主要工作，其次是进行良好的新测试和测试范围。
– Niels van Reijmersdal
17年2月2日于16:21
@NielsvanReijmersdal提出了一个很好的观点-现有测试的维护优先于添加新测试，否则每次损坏的测试都会丢失测试覆盖率，而不能通过添加测试覆盖率来弥补。
–迈尔斯
18年3月13日在10:08
@Myles-这就是我最后一句话的原因。最重要的是使现有测试保持良好状态。
–凯特·保罗（Kate Paulk）
18年3月13日在11:17
@KatePaulk-我重新阅读了您的句子，意识到我是第一次错过了它。一如既往的好答案。
–迈尔斯
18年3月14日在12:49
#2 楼
在这里主要要了解的是没有灵丹妙药。您有很多其他问题要解决。我建议您安排一次会议并讨论以下几点。我们的团队与开发该软件的团队无关。好吧，那是个问题。请解释更多为什么不这样做。为什么不能更改？
“我们得到了用户故事”。那是命令和控制语言。您为什么不为故事做任何先期准备？与测试人员进行10分钟的对话可以节省一个星期的开发工作，与开发团队进行10分钟的对话也可以节省一个星期的测试错误事件的价值。
”产品负责人不知道谁编写了测试用例”。认真吗你想要建议吗？来吧，您已经知道这很荒谬。请勇敢地与他们交谈。
“如果进行UI或任何其他更改，我们的测试用例可能无法在新版本中使用。”什么？当事情发生变化时，您不会陷入困境。这是功能失调吗？是的
谁来运行测试？使开发人员能够运行您的测试，并在测试因开发变更而中断时帮助维护它们。如果开发人员必须自己运行通过测试，那么他们就无法传递破损的代码。
如果另一个团队编写软件部分对我来说并不重要，我只需要关注：
作为团队的一部分，它会在编写一行代码之前预先了解方法和高层意图以及如何测试建议的解决方案。
与业务并谈论您喜欢自动化的程度-但不参与“前期工作”是他们需要解决的一个主要问题，这样才能有效发挥作用并持续聘用您
在我的测试中使用敏捷实践，以便如果应用程序状态是固定的，我会编写质量高，可维护且自动化的同行评议
最终，如果企业说“这就是事实，请接受并编写自动化”，然后说您要基于行业的良好做法创建质量解决方案。否则，您将工作在尊重您，团队和良好原则的地方。我的建议是，将其放置在线路上以解决这种混乱的状况。该语言需要一些工作，但我不会帮您修改。不容易，需要很多技巧。
评论
我想补充一点：“要求” OP的获得与我书中的敏捷没有太大关系。我同意@michael：这需要很多技巧，说话和耐心。
– Ray Oei
17年11月30日在13:54
+1更改了对方法和高级意图@RayOei的要求
–迈克尔·杜兰特（Michael Durrant）
17年12月1日在12:43
#3 楼
我们如何才能使这种情况正常工作？在新的软件版本中。
现在，产品所有者希望我们使用Agile
方法来自动化测试用例。
获取您的组一个敏捷教练，并让此人与开发团队的教练进行沟通，并找出一种对双方都有利的工作方式。
盲目地复制敏捷方法只会导致“货运崇拜”敏捷，这听起来您的团队已经深陷其中。
我有一些经验：
用敏捷方法自动化测试用例，但不能参与其中开发软件的敏捷团队的
成为敏捷开发团队的一部分！确保团队在每次迭代中都交付运行良好且经过测试的软件。不添加测试作为事后的想法。
评论
如果其他团队允许您描述的情况，则无论他们重复该咒语多少次，他们都不敏捷。 “敏捷”并不是魔咒，它意味着遵循敏捷开发原则，而您的设置远非如此。我确实同意这些答案，它们试图在您遇到的不利情况中发挥最大的作用。我的感觉是，您的团队已被设置为将来失败的方便替罪羊，因此请准备在不可避免的情况下放弃飞船灾难罢工。因此，以上评论有很多要点。这不是敏捷的，这不是很好。这甚至不是很好的瀑布。
我同意。没有“孤立”比任何敏捷实践（例如用户故事或故事点）更为重要。 “流程和工具上的个人和交互”。将您的测试人员带入敏捷团队，而不是让他们外在，这就是您拥有敏捷团队的方式。一个敏捷团队，而不是两个使用敏捷实践的工作组。