私人 beta 测试通信和基础设施答案

【问题标题】：Private beta test communication and infrastructure私人 beta 测试通信和基础设施
【发布时间】：2010-11-01 00:58:17
【问题描述】：

因此，您的商业应用正处于开发的中间阶段。它已经足够可用，但仍需要改进、扩展和错误修复。它远不能交付，但它足够稳定和完整，让您的开发人员和内部测试人员/用户觉得是时候从真实用户那里获得更多反馈了。

因此，您需要进行更广泛但仍然封闭的 Beta 测试，可能是从想要贡献和提供反馈的现有用户/客户中选择的。

previous SO question 表明，使用 beta 测试人员的最佳方式是确保双向通信良好。我们希望实现这种通信！

_{（来源：ifac.cnr.it）}

所以问题是要找到组织和允许开发人员和普通测试人员之间以及测试人员自己之间的沟通的最佳方式？

过去，我们在这里一直只是设置一个简单的电子邮件邮件列表，将秘密测试人员添加到列表中，并让他们通过电子邮件发送一个集中的地址来发布，该地址在列表中的每个人之间共享。这很粗糙而且很老套，但我们已经这样做了 15 年，而且效果很好，尤其是对于我们大约 10 名测试人员的外部小组。

但肯定还有其他方法，也许最好探索一下。您为自己的项目设置了哪些 beta 测试基础架构？目标和要求含糊不清，但有些要点可能值得考虑

设计这种甚至可以组合的测试版支持基础架构有一些明显的选择。

查看 SourceForge 也很有用，它适用于不需要保密、邀请或课程的开源应用程序，但每个项目都有一个论坛和 bugtracker。甚至考虑即将推出的平台/范式（例如Google Wave.

）也可能很有趣

我的问题：您使用什么系统来组织内部/外部的 Beta 测试人员，哪一个系统在增强开发过程方面能带来最好的回报，而无需费力或烦人地管理一些过于复杂的系统？

我将其作为社区 wiki 发布，因为很明显不会有唯一的最佳答案。

【问题讨论】：

【解决方案1】：

我建议有一个类似trac 的网站，或vBulletin's project addon.

就我个人而言，我构建了一个适合该解决方案的解决方案，称为Bugzilla，但任何项目管理套装都应该可以做到这一点。

【讨论】：

【解决方案2】：

我们的 Beta 版测试人员通过我们的本地测试人员 (QA) 通常通过电子邮件而不是直接与开发人员进行交流。
- 这允许 QA 通过合并重复项、删除非错误（功能请求）等来管理错误/问题。
- 他们还将在问题返回给用户之前重新测试问题所以对他们来说完全理解错误/问题很重要，他们可能会构建一些必要时进行自动化测试。
- 他们对其进行记录以使其保持一致，一些 beta 测试人员是优秀的测试人员，但不是擅长文档。
- 任何巨大/复杂的问题都可以作为一个小组（开发人员、QA、Beta 测试人员）进行讨论
我们使用 Team Foundation Server，但就像我说的那样，我们不允许 beta 测试人员访问它。这一切都由 QA 管理。我们不是与 TFS “紧密耦合”，而是完成了这项工作。

他们的方式对我们很有效......

【讨论】：

这是向开发人员获得一致且高质量的反馈的好主意。这似乎是错误聚合的理想选择。它可能对其他目标（例如头脑风暴改进）没有用处，但对于错误，如果您有那个 QA 层来处理界面，它可能是双赢的。