什么是现实（但快速）的测试版本计划？

Question

我的团队接近部署我们的应用程序，我们即将与一些特定客户进行内测。我想知道生成新测试版本的实际时间表是多少，以及在我们可以称第一版足够稳定以便发布之前，我们可以实际期望需要多少这样的周期。

该应用程序本身是一个医疗成像应用程序，所以它绝对不会崩溃或损坏数据。许多用户还将持续使用该软件至少四到八小时，因此我期望正常的用户错误会很快遇到。应用程序与特定的硬件绑定，如果他们有硬件，他们将需要这个应用程序或以前版本的应用程序来运行他们的硬件。

当然，现在，现在也有压力从上面释放它！因为他们支付我的工资，所以我有责任按照他们的指示行事，尽管我可能会对快速发布产生任何疑虑。

我在想，在以下情况下可以发挥出：

1. 两周的周期时间。我们有一组特定的用户，说3到5个站点，当他们遇到错误时，我们修复它们。我认为这个周期时间非常快，但我已经可以感觉到这将是如何部署的权力。对于这种方法，我们将产品锁定到特定版本，并且在下一个版本（可能是50版之后）中修复任何积累的错误。
2. 六周周期时间。我们有相同的选择用户组，但是该组可以增长，并且随着它的增长，我们将按照步骤1进行操作。速度不如1，但肯定比较谨慎。问题是，用户可能会产生这样的印象，即产品过于错误（如果它们遇到错误），并且在我们发布另一个版本之前不会有这种印象，此时他们可能不再在意。由于前面提到的硬件锁定了，这种繁琐的印象可能只会转化为轻微的抱怨，而不是失去的销售。但是，每个较新的beta版本都将比上一次更加审核。
3. 只要修正了错误，就可以将固定版本交到用户手中。我们有一个构建服务器，我们有几个测试人员，而且我们很快就会做出响应（你甚至可以说'敏捷'）。只要修复程序不会破坏软件需要的某些其他行为，就像我们修复错误一样快地修复错误，是否存在缺陷？如果我们采取这种方法，我们会做周期，还是只是一个测试'时期'？

我意识到，这些问题因用户而异，而像暴雪或Gmail测试版这样的东西有点长。我仍然想知道我应该如何回应管理层关于测试版应该投入多长时间的问题。

Answer 1

在我们的案例中，我们让客户的反馈决定了我们的周期。在发布初始测试版之后，我们会听取反馈意见。有时候会有一个灾难性的bug，我们暂停推出测试版，修复它然后恢复。我们根据客户重要性收集错误，然后在抱怨消失后再推出更新。最终，客户的看法是最重要的（参考速度），因此平衡他们对管理层所要的投诉是棘手的方面。在我们的案例中，我们通常会根据错误的数量和紧急程度，在2-4周的时间内进行。

Answer 2

这似乎是一个问题，在您的第一次反馈来自最初的测试版发布后不久就会回答。如果客户普遍感到高兴，并且问题比结构更美观，则计划缩短测试阶段。如果你发现相反的话，准备管理层为更深入的测试阶段做准备。

我不知道您的应用程序的具体细节，但我会认为一套发布计划会更容易让您的客户跟上。当客户确实发现优先级较高的问题时，很高兴听到该解决方案已经投入使用，并且只要距离不到几个月，它将在2周甚至6周内出现在下一个版本中。 '补丁'除非被严格区分可能会导致比解决问题更多的问题，因为客户拥有奇怪且截然不同的代码库，这将很难再现问题。

Answer 3

与数字1一起去吧。毫无疑问，这可能是最好的方法。 ＃2显然不理想，因为周期时间长。 ＃3是诱人的，会给你带来难以置信的麻烦。这就是为什么：如果您将修补程序部署到需要它们的人身上，那么您会完全失去任何理性的版本控制方案，并且跟踪哪个客户有哪些修复程序以及哪些版本最棘手。

Answer 4

我见过一对一的发布时间表。第一个版本计划，更大，包括功能，aybe 6-8周或有时更多。第二个是计划的修正，每2周一次。所以每10-12周你有两个版本。