开放测试版与针对webapp的封闭测试版的任何好处/缺点

Kam*_*amo 8 language-agnostic project-management web-applications

这不是关于代码的问题,但它与编程有关.我们有一个可以进行beta测试的网络应用程序.有没有人注意到测试者给出的反馈的质量或数量或任何其他因素,开放式测试版与封闭测试版之间有什么区别?

Eva*_*ice 15

使用封闭测试版,您可以限制用户数量

这可能看起来不是什么大问题,但考虑一下......

封闭测试版:

  • 通过要求用户根据他们期望使用应用程序的方式编写提案来选择用户群
  • 您向100位用户发布备受期待的应用程序,第一个月没有额外的邀请
  • 这些用户定期使用该程序,并挑选出在测试版前QC中出现的大多数常见错误.
  • 那些用户感到很荣幸能够使用该应用程序,因此他们向所有人吹嘘他们对它的喜爱程度(大量的免费PR)并且不太愿意将其丢弃,因为它仍然是"封闭测试版"
  • 大多数常见错误在第一个月被识别出来,并且第一组beta测试者将获得有限数量的邀请以进入测试版的第2步
  • 或者,应用程序中仍有一些噩梦般的错误,并且进一步的邀请被推迟审核,直到下一个发布周期.

公测版:

  • 您觉得您的应用程序已经足够精致,因此您可以将其作为公共测试版发布给大众
  • 更客观的用户开始查找和报告错误
  • 不幸的是,提交的错误数量使错误跟踪器膨胀,因此发现错误变得非常困难
  • 由于很难找到错误,重复项开始弹出,错误跟踪器更加膨胀
  • 你花费了大量的精力,试图保持bug跟踪器的清洁,同时还试图修复代码中的错误
  • 不太客观的用户给应用程序一个镜头,发现"不是一切"完美无缺或按照预期的方式工作(直观)
  • 那些不太客观的用户跑到他们的小博客上并开始制作像'OMG WTF srsly,[appName]糟透了理由[x]和理由[y]和[z]
  • 所有小'嗡嗡声博客'都在你的应用程序的名称上踩踏,因为这让他们觉得'有权'公开咆哮任何/一切
  • 谷歌索引所有的博客咆哮,因为它们包含许多与您的产品相关的指示性关键字,因此当您在谷歌中输入您的应用程序名称时出现的前2页通常涉及"[appName]糟透了"的内容.

"封闭测试版"的最大好处之一是,您可以根据允许的用户数量和允许的用户类型来控制工作量.

你需要一群"客观"的用户来支持你对抗"主观"用户,因为阶梯群体的主要目的是在网络上寻找一个应用程序来捣乱垃圾并制造大量耸人听闻的反炒作; 一切都是为了吸引更多流量到他们的博客.

如果你想要一个非常好的例子来说明如何成功地运行封闭式测试版Google.

  • 有了gmail,他们开始有一个严格限制的封闭测试版
  • 他们修复了第一轮beta测试者发现的任何明显错误
  • 更多的邀请被发出
  • 然后他们开始从beta用户那里收集要在他们的webapp中实现的新功能
  • 它们结合了功能,同时修复了错误
  • 他们发出更多邀请
  • 继续跟踪功能请求和错误提交
  • 当它被充分抛光时,它们会将其释放为开放式测试版
  • GMail保持公开测试3年

为什么?谷歌很聪明.如果一些随机模糊的bug在公开测试版中出现2年,那么任何人都可以真正为它删除谷歌,因为它仍然是"测试版".这就像谷歌的一点点说法,这很好,但我们并不完全满意.即使他们在测试版的最后两年没有触及代码库,它仍然给人的印象是"他们仍然在完善它".

这让我想到了为什么你想要限制beta的最重要的一点......

创建后,您无法改变人们对您产品的看法

观看这个,"如何忽略营销,并在两个简单的步骤中变得无关紧要",看看我的意思.这很容易成为我见过的最有趣的演讲之一.

注意:我个人参与了多个'封闭'的测试版.即,GMail,Google Wave,Boxee,Songbird等.