我的团队即将部署我们的应用程序，我们即将与一些选定的客户进行封闭测试。我想知道生产新的 beta 版本的实际时间框架是多少，以及在我们称第一个版本足够稳定以供发布之前，我们实际期望需要多少这样的周期。
该应用程序本身是一个医学影像应用程序，因此它绝对不会崩溃或损坏数据。许多用户还将每天连续使用该软件至少四到八小时，因此我预计会很快遇到正常的用户错误。该应用程序与特定的硬件相关联，如果他们拥有硬件，他们将需要此应用程序或应用程序的先前版本来运行他们的硬件。
当然，也有来自上面的压力，现在，现在，现在！由于他们支付我的薪水，我有义务听从他们的指示，尽管我可能对快速释放有任何疑虑。
我认为可能会出现以下情况：
- 两周的周期时间。我们有一组选定的用户，比如三到五个站点，当他们遇到错误时，我们会修复它们。我认为这个循环时间快得离谱，但我已经感觉到这将是权力想要部署的方式。对于这种方法，我们将产品锁定到一个特定的构建，并且我们在下一个版本中修复任何累积的错误（可能是 50 个构建之后）。
- 六周的周期时间。我们有相同的选定用户组，但该组可以增长，随着它的增长，我们会像第 1 步那样行动。没有第 1 步那么快，但肯定会更加谨慎。问题是，用户可能会觉得产品有太多错误（如果他们遇到错误），并且在我们发布另一个版本之前不会有这种印象，此时他们可能不再关心。由于我之前提到的硬件存在这种锁定，这种错误印象可能只是转化为轻微的抱怨而不是销售损失。但是，每个较新的 beta 版本都将比上一个更经过审查。
- 尽快修复错误，将修复的版本交到用户手中。我们有一个构建服务器，我们有几个测试人员，而且我们的响应速度非常快（您甚至可以说“敏捷”）。只要修复不会破坏软件需要的其他一些行为，就像我们修复错误一样快速地发布错误修复是否有缺点？如果我们采用这种方法，我们会做周期，还是只是一个测试“周期”？
我意识到这些问题因用户而异，而且像暴雪或 Gmail 测试期这样的问题有点偏长。我仍然想大致了解我应该如何回应管理层不断提出的关于它应该处于测试阶段多长时间的问题。