如果你想走得快，你需要假设一旦某个东西经过测试并在一个循环中工作，它将继续在那个循环中工作。如果您不能做出这样的假设，您要么需要花费更多时间进行测试（自己或在他人的帮助下），要么您的开发人员需要交付更高质量的代码。除了您和您​​的开发人员之外，没有人可以决定如何交付更高质量的代码；你走的路取决于你的情况。

最初几年，我公司也有 3 名开发人员和 1 名测试人员。现在我们有 4 名开发人员和 2 名测试人员，但我们仍然采用两阶段的方法进行测试：功能测试，我们专注于我们知道已经改变的事情，然后是回归测试，我们在整个产品中测试关于发生了什么变化。一旦功能完成代码，功能测试就开始了。

当大多数/所有功能都完成并经过功能测试时，回归测试开始。它是一个安全网，用于在可能与已更改内容无关的区域中捕获错误。您是否需要单独的回归测试将取决于您的产品的结构以及从一个 sprint 到下一个 sprint 的变化量。

这是困扰我工作环境的确切问题，并且还没有找到一种行之有效且始终如一的策略。

一些有帮助的策略和技术是：

• 测试专家与编码专家一起进行单元测试。即使测试专家不是编码员，了解单元测试的覆盖范围并与编码员讨论它们也可以让整个团队更有效地利用时间。
• 代码完成后，编码专家执行手动测试。单元测试开发期间的讨论可以帮助没有太多测试经验的人进行快乐路径测试。
• 在开发和探索性测试期间，测试专家确定要在最后一天半执行的核心测试，以及旨在清除可能有问题的区域的少量测试序列。这些首先被执行，而代码专家正在执行验收和快乐路径测试。如果团队是真正的敏捷而不是“scrum-fall”或“agile-fall”，这将有很大帮助。
• 测试自动化，无论是基于 API 还是基于 GUI 的都在后面运行 sprint，以便自动化专家在稳定的代码库上工作。

坦率地说，根据我的经验，没有最好的方法——只有一组可以用来最小化问题的技术和策略。

在我看来，解决这个问题的关键有两点：你必须自动化你的大部分测试，你必须使用严格的测试优先方法。这样做，您将能够首先指定测试并为每个版本立即自动运行它们。你也会以这种方式捕捉到任何回归。

当然，这根本不容易实现。有些事情比其他事情更难自动化。而且，首先自动化测试（尤其是 UI 测试）依赖于成熟的测试和开发基础设施。一个提示是使用数据驱动和关键字驱动的测试（绝对不是任何类型的记录/重放）。

总是需要一些手动测试，即使只是为了探索性测试，但在敏捷项目中进行测试的第一步总是尽可能地自动化，并且尽可能快。

这是敏捷团队中非常常见的情况。为了解决这个问题，我们有一大套由开发人员和测试人员编写的不同粒度的自动化测试。然而，这还不够。为了尽早交付部分完成且易于测试的功能，需要不同的开发人员思维方式。

也就是说，想象一下开发人员正在编写一个定期运行并且可以通过 UI 进行配置的 Windows 服务。那个开发者。应尽快将 Windows 服务交付给 QA，并以一种简单的方式验证其行为并继续使用 UI。

基本上，测试人员不能等待太多来测试新功能，而开发人员不能等待测试人员。然后，提供小功能可以帮助每个人在工作中有所作为。

另一件事是，即使需求可能发生变化，开发人员也必须尽量不要更改代码，而是要解决它。