language-agnostic - webapp 开放测试版与封闭测试版的任何好处/缺点

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




这不是关于代码的问题，而是与编程相关的问题。我们有一个 Web 应用程序可以进行 Beta 测试。有没有人注意到在测试人员提供的反馈的质量或数量或任何其他因素方面，公开测试版与封闭测试版之间有什么区别？

Answer 1

使用封闭测试版，您可以限制用户数量
这可能看起来没什么大不了的，但是，考虑一下......
内测:

用户群是通过要求他们写一份关于他们希望如何使用应用程序的建议来选择的

您在第一个月没有额外邀请的情况下向 100 个用户发布了备受期待的应用

这些用户定期使用该程序，并挑选出大多数在预测试版 QC 中漏掉的真正常见的错误。

这些用户感到很荣幸使用该应用程序，因此他们向每个人吹嘘他们有多喜欢它(大量的免费公关)并且不太愿意将其丢弃，因为它仍然是“出于某种原因的封闭测试版”

大多数常见的错误都是在第一个月确定的，并且会向第一批 Beta 版测试人员发出有限数量的邀请，以进入 Beta 版的第 2 步

或者，应用程序中仍然存在大量错误，进一步的邀请被推迟到下一个发布周期进行审查。

公测版:

你觉得你的应用程序已经足够完善，所以你将它作为公共(public)测试版发布给大众

越客观的用户开始发现和报告错误

不幸的是，提交的错误数量之多使错误跟踪器膨胀，因此查找错误变得非常困难

由于很难找到错误，重复项开始出现并且错误跟踪器更加膨胀

您花费了 x 量的精力来试图保持错误跟踪器的清洁，同时还试图修复代码中的错误

越不客观的用户尝试使用该应用程序并发现“并非所有事情”都能完美运行或以他们预期的方式运行(直观)

不那么客观的用户会跑到他们的小博客上并开始发表类似“OMG WTF srsly，[appName] 很糟糕的帖子，理由是 [x] 和理由 [y] 和 [z]

所有的“嗡嗡声博主”都在践踏你的应用程序的名字，因为这让他们觉得“有权”公开谈论任何/所有事情

谷歌索引所有的博客咆哮，因为它们包含很多与你的产品相关的指示性关键词，所以当你在谷歌输入你的应用程序名称时出现的前 2 页通常涉及类似“[appName] 糟糕透顶”的内容。

“封闭测试版”的最大好处之一是，您可以根据允许的用户数量和允许的用户类型来控制工作负载。
你需要一支“客观”用户大军来支持你对抗“主观”用户，因为阶梯组的主要生活目的是在网络上寻找垃圾应用程序并制造大量耸人听闻的反炒作；所有这些都是为了吸引更多流量到他们的博客。
如果你想要一个很好的例子来说明如何成功运行封闭测试版，请查看谷歌。

使用gmail，他们有一个严格限制的封闭测试开始

他们修复了第一轮 beta 测试人员发现的任何明显错误

更多邀请发出

然后他们开始从测​​试版用户那里收集要在他们的 web 应用程序中实现的功能的新想法

它们包含功能，同时修复错误

他们发出更多邀请

继续跟踪功能请求和错误提交

当它足够完善时，他们会发布它以开放测试

GMail 仍处于公测阶段 3 年

为什么？谷歌很聪明。如果在公开测试版的 2 年后突然出现一些随机的晦涩错误，没有人可以真正因为它而将谷歌扔掉，因为它仍然是“测试版”。这就像谷歌的说法一样，它很好，但我们并不完全满足于好的。即使他们在测试版的最后两年没有接触代码库，它仍然给人一种“他们仍在完善它”的印象。
这让我想到了为什么要限制测试版的最重要的一点......
一旦创建，您就无法改变人们对您的产品的看法
看这个，"How to Ignore Marketing and Become Irrelevant in Two Easy Steps"看看我的意思。这很容易成为我见过的最有趣的演示文稿之一。
注意:我亲自参与了多个“封闭”测试版。即，GMail、Google Wave、Boxee、Songbird 和其他一些。