您在此处的选项将由两个测试周期之间的依赖关系和重叠控制。

首先分析它们的短期和长期——资源、测试基础设施、测试结果、业务影响

然后，正如您提到的，您不能同时运行两个版本，尝试发现重叠，看看可以做哪些工作来帮助两个测试周期。

有没有 ？如果是 - 太好了，你可以支持它。

如果不是（并且为了不重叠工作领域）尝试将资源、活动解耦，甚至考虑外包给另一个团队

作为最后的手段，优先考虑并为业务/项目领导提出建议清单，以便接听电话，哪些项目需要放弃？

无所畏惧并发布无法维持的消息是一种更好的方法，而不是在可交付成果的压力下挣扎并在两者都失败...

好的，如果我理解正确，这是您的情况：

• A. 你有很长的测试时间，比如 2 周，而且不能缩短。
• B. 你必须在这 2 周内多次发布，比如每周一次。
• C. 你不能同时运行两个版本。

是时候进行一些艰难的爱情了，必须给你一些东西：

1. 确定一个较小的测试子集以减少您正在测试的内容，但这违反了 A.
2. 减少发布的数量，这样您每两周只发布一次，但这违反了 B.
3. 同时运行两个版本，这违反了 C.
4. 使用自动化来减少执行时间，这又违反了 A.

因此，简单地说，需要打破三个规则之一，否则您只需要接受这样一个事实，即您的测试永远不会在任何给定版本上完成。

你所说的问题不是一个可以解决的问题。假设这是在瀑布过程结束时被困的测试人员绝望地寻求帮助，那么翻转的答案是“变得更加敏捷”。

当然，这种情况下的常见问题是 QA 团队除了“测试签核”之外几乎没有什么影响力。更糟糕的是，如果发布了错误，QA 团队就会被召集到地毯上。

以下是一些需要考虑的杠杆点。

• 拿出你的问题陈述并扭转它。问“我们真正想要完成什么？”。这个问题有很大的力量去触及看似棘手的问题的核心。
• 问为什么五次。
• 以较少的测试作为实验发货。如果出现问题，有办法“拔掉插头”。
• 告诉开发团队 QA 团队不再进行“测试签收”。开发人员决定什么时候一个功能足够稳定可以发布。QA 团队负责提供测量和数据以帮助他们做出决定。
• 选择一种方法来改进整个流程，并让一位开发人员在发布周期中试用它。
• 每天让一件事变得更好。有时，解决一个难题会导致它意外崩溃。
• 保持积极的态度。尽可能多地关注团队做得好的事情。
• 重复。为您希望看到的一项改进选择一个流行语（“设计可测试”对我来说是一个很好的）并重复它直到它流行起来。
• 确保你不是问题的一部分。不要说“我们不能……”、“我们永远不会……”、“鲍勃是个白痴。”等等。而是考虑说“我们还没有……”、“我们还没有开始……”，“鲍勃没有错……”
• 当你的意思是“但是”时，开始说“和”。当你的意思是“他们”时说“我们”。“我们无法在不到两周的时间内完成一个测试周期，我们需要每周发货一次。”

解决看似棘手的问题就是要找到一些杠杆作用。寻找杠杆是跳出框框思考的经典练习。你必须发挥你的热情、耐心和坚持。寻找小胜利并庆祝他们以获得一些动力。

这将取决于您的稳定性目标是什么，您是否需要 2 周的时间才能生成已报告的错误或“总是以这种方式完成”？

我必须在之前的工作中保持一个稳定的环境，这样做的理由是因为我们需要运行负载并尝试找到通常只在 X# 天后才出现的缺陷。尽管我们仍然有发布的版本，但稳定性环境必须按时运行，尽管我们只会在达到预期时间后进行更新，然后再进行更新。

如果您必须在这段时间内运行您的测试，您可能无能为力，如果您可以按照建议缩短它，然后与设置测试的人讨论您可以做些什么来使其现实并适合一个你更舒服的时间。