我怎么可能在每次迭代中测试所有内容？
这是一个常见的经典问题，答案见仁见智，下面是一种比较普遍的观点。
这取决于你对“所有内容”的定义。
你可能指的是对整个应用程序进行全面的回归测试，包括所有功能、负面路径、边缘情况等。你说得对——除了一些非常小的产品外，你不可能在每次迭代中做所有这些事情。
但事实是：你不应该在每次迭代中进行这种全面的测试，你不应该觉得有必要这样做，也不应该被要求这样做。
迭代是敏捷软件开发中的概念——在软件长期开发并在最后一次性交付的模式中，“迭代”这个词没有意义。
迭代开发软件的全部意义在于引入小而有价值的变更并将其交付给用户。由于变更很小，产品的大部分与之前相同，因此不需要再次进行全面验证。假定它在过去已经被测试过了。
但也许变更的范围比看起来更广，或者它们在程序的其他部分引入了意想不到的后果。
这些都是合理的担忧。然而，开发人员引入的大多数变更并不影响整个系统，你不应该默认认为它们可能会这样。
值得补充的是，如果团队经常发现自己处于变更波及整个系统并需要全面测试的情况，那就是存在更深层次问题需要解决的迹象。
这可能意味着系统架构有问题，团队应该认真考虑偿还技术债务。 或者也许软件更像是一个原型、概念验证，而不是解决方案。在这种情况下，在团队更好地理解需求和利益相关者可以批准一种方法之前，可能不需要全面测试。许多测试人员在这种环境中工作时感到困难。他们将自己的角色视为可能存在缺陷的软件与用户之间的最后一道防线。他们对用户可能得到未经全面测试和验证的软件感到不安。
如果你是其中之一，你需要理解这种风险是经过计算的，也是重视短迭代和频繁交付的软件开发模式固有的。这些想法相互强化。产品没有经过全面测试，这意味着可能存在用户遇到前未被发现的错误、失误和问题。但正因为产品没有经过全面测试，它可以更快地发布。当团队了解到软件中的问题时，他们可以修复并进行新的发布。
如果这个论点不能说服你，我建议你尝试一下。承认你个人并不认同这种方法，但如果这是团队想做的，就不要阻止它。在几次发布中保留你的保留意见，看看会发生什么。你可能会发现产品的质量实际上并没有明显低于以前。如果结果显示质量确实下降了，那么你将有坚实的经验数据向团队展示。大多数人会同意这些结果是不理想的，需要某种改变。
最后，你不应该被要求在每次迭代中进行全面测试。
就我个人而言，我在这方面没有太多经验——我从未在试图这样做的团队中工作过。虽然我不能说在这种情况下什么方法可能有效，但我猜想首先要做的是理解这种要求背后的立场。也许需要教导利益相关者迭代的权衡；或者也许团队需要采用更谨慎的软件开发模式，以牺牲速度为代价。
我还没有提到自动化，它对以上所有观点都有贡献。作为测试人员，你的工作应该得到自动化的支持，至少每天运行一次，并提供关于产品状态的最新可靠信息。虽然自动化有限制，不能检查所有内容，但它可以检查一些行为。
你应该了解在你的项目中自动化能做什么和不能做什么，这样你就可以对哪些功能和路径不需要花费太多时间做出明智的决定。你应该对自动化结果有信心。当有人要求你反复执行特定测试时，你可以将其视为讨论花些时间改进自动化的机会。
在这篇文章的开头，我说过答案取决于“所有内容”的含义。它可能意味着全面测试，这是我到目前为止关注的重点。但它也可能意味着迭代期间发生变化的所有内容。
确实会发生开发人员完成了如此多的工作，以至于团队中的测试人员应接不暇的情况。不久前我就遇到过这种情况，对我们有效的方法是推动整个团队的所有权。大多数开发任务不需要专门的测试人员来测试或验证——它们只需要由没有编写代码的人来测试。在我们的案例中，我们所要做的就是在站会上表明问题，团队其他成员很快就想出了解决方案——一些开发人员应该停止接受新工作，而是专注于测试已经完成的内容。为每个任务明确列出完成的定义和验收标准肯定会有所帮助。
然而，处理这个问题的最好方法是主动避免它。总的来说，作为测试人员，尽量尽快测试变更。不要等到迭代结束。如果团队实践基于 PR 的工作流程，你可以尝试在代码合并之前测试创建的开发版本。让 CI 系统为每个 PR 构建工件会有所帮助，但另一种选择是在你自己的机器上设置构建环境。对于特别大的功能，在代码编写之前给开发人员反馈，并鼓励早期分享代码和想法。每日站会（如果有的话）是表达这种对话愿望的好机会。你也可以考虑主动联系开发人员并私下讨论。
可能会发生尽管使用了上述所有建议，测试人员在冲刺结束时仍然常常工作过载的情况。根据我的经验，这种情况更有可能发生在试图严格遵循僵化的 Scrum 结构的团队中，迭代周期为一到两周。由于工作在冲刺开始时分配，会有一段时间开发人员专注于他们的工作，而测试人员没有太多事情可做。这种动态在冲刺结束时会发生变化。在这种情况下，我强烈建议在回顾会议上提出这个问题。大多数人会同意这是一个长期不可持续的系统性问题。像往常一样，对于自组织团队来说，由团队自己想出解决方案。只要记住监控情况，保留数据，如果没有明显改善，就再次提出这个话题。
