在推到UAT之前重新测试整个sprint是正常的吗？

Question

我在软件行业有不到5年的工作经验，这是我第一次做QA。

在sprint中的故事转移到UAT之前，我应该在QA和UAT之间的环境中，在1天内重新测试每一个故事。

这样做的目的是让多个团队拥有自己的QA环境，在这里他们只测试自己的特性。额外的环境是确保由不同的团队开发的特性不相互干扰。

这一期望对我来说似乎令人惊讶。我认为，从技术上讲，这并不是一项值得完成的工作，因为测试用例已经编写完毕，但在一到两天的时间里，这似乎仍然是很多工作。

这对于敏捷项目来说是正常的/合理的/典型的吗？

Answer 1

在Scrum中，每个sprint都以一个具有潜在可移植性的产品结束。如果需要从技术角度对特定的构建进行回归测试，那么您的问题的答案是肯定的。你实际上要测试的比你所说的要多得多。也许还有另一种解决方案，但我所知道的处理这种问题的唯一方法是健壮的自动化测试策略。

Answer 2

很难回答“什么是典型的”，因为不同类型的客户对如何在他们的系统中部署软件有自己的要求。维护和部署自己的软件的公司(如Netflix、AirBnB、Stack等)会发生各种各样的事情。对于那些需要向第三方移交部署的公司。

敏捷背后的理念是，您可以根据需要进行部署。DevOps扩展了这一思想，并尽可能地自动化部署和测试过程。对于完全实现而言，一旦更改被提升，DevOps将实时推动它们。

我在一个行业里工作，我们必须在私有网络上部署，这意味着我们不能真正实现所有事情的自动化。在我们的情况下，我们会做这样的事情：

• 在特性分支上进行开发，并在完成时发出拉请求。
• 对开发流的每一次更改都会导致我们的CI服务器构建并部署软件到测试服务器。
• 自动测试针对该实例运行，然后是手动测试。
• 我们部署在客户网络中的暂存服务器上。
• 客户执行UVT (用户验证测试)，只是与UAT不同，因为用户无法停止发布
• 最后，向第三方提供安装说明，以便在生产中执行安装，并且有正式会议批准该操作。

到了我们在暂存服务器上部署时，我们使用DevOps来确保产品是正确的，并且我们没有在任何关键功能上倒退。但是，我们确实发现了只有在客户网络中部署时才存在的东西。因此，我们必须手动为我们的客户执行一个完整的回归测试。

当您无法完全控制部署环境时，您会发现需要进行额外的测试。这种情况在商业世界中并不常见，而在行业或客户较为保守的情况下则更为普遍。