Hmmm...Beta is for a product you think is finished...until you give the Beta users to play with it and they break it in ways you haven't thought of. So, yes, go with Beta, unless you want to burn your product on many users.
How about internal QA? They find bugs too, you know. Only release a beta to customers when you have no known serious bugs.
Also, always test adequately. If time is pressing and you haven't finished all your tests, then that's just tough. Finish testing, whether you have time or not.
My answer is that there are many factors that would determine which makes more sense:
1) Consequences of bugs - If bugs would result in people dying, then I think a beta would be a bad idea. Could you imagine running beta software on a nuclear reactor or on a missile system? On the other hand, if the consequence is fairly minor like if there is a temporary outage on some fantasy sports site, that may not be so bad to put out in beta.
2) Expectations of users. Think about the users of the application and how would they feel about using something that is a "beta"? If this would make them scared to actually use the software and be afraid that it is going to blow up on them regularly and be riddled with bugs, that may also play a role.
3) Size of the application. If you are going to build something very large like say an ERP to handle the legal requirements of 101 countries and contain hundreds of add on modules, then a beta may be more sound than trying to get it all done and never get to where you have customers.
4) Deployment. If you are setting up something where the code is run on your own machines and can easily be upgraded and patched, then a beta may be better than trying to get it all done right in the beginning.
5) Development methodology. If you take a waterfall approach, then no beta is likely a better option, while in an agile scenario a beta makes much more sense. The reason for the latter is that in the agile case there will be multiple releases that will improve the product over time.
Just a few things I'd keep in mind as there are some cases where I easily imagine using betas and in other cases I'd avoid betas as much as possible.
Without knowing what the app is and what it's audience will be, I think that would be a hard choice to make. However if it's an Open Source project, it seems like the consensus is usually "Release Early and Release Often".
The real question is this: Do you know exactly what your users what?
If you answer yes, then design and build everything and launch it with no Beta.
If you answer no, then Beta is the way to go - your users will help define your software and they will feel more a part of the process and have some ownership.
I say Beta. But I disagree with your premise. You should never release semi-anything software. The software released as Beta should at least be feature complete. This way your users know what they're getting into.
As far as finding bugs. Internal testing is best. However, anyone that has released software knows that no matter what the user will find a new and interesting way to break it.
I would suggest alpha testing first, to a select group, that is not feature complete, so they can help you find bugs and determine which features are needed.
Once you get what is thought to be feature complete, then release it to a larger group, mainly to find bugs, and to get comments on feature changes, but you may not make feature changes unless there is something critical.
At this point you are ready for release, and you go back to step (1) for the next release.
After finishing (you think) your software, and believe that there are no serious bugs, conduct alpha testing. Make the software available within the test staffs of your company, fix the bugs reported.
Next, release the software to customers as beta testing, collect comments, fix bugs & improve features.
You shouldn't release a beta until you feel that the product is bug-free. And at that point, the beta users will find bugs. They will, trust me. As far as letting the beta users 'guide the design', probably not a good idea - you'll end up with software that'll look like the car that Homer Simpson designed. There's a reason why beta users aren't software designers.
As far as the second option - unless you are an extraordinary tester, you will not be able to test it as well as end-users (they will do the silliest things to your software). And if you "test it with whatever time you give yourself (or are given)", you will not have enough time.
发布评论
评论（10）
嗯...Beta 版适用于您认为已经完成的产品...直到您让 Beta 用户使用它，然后他们以您未曾想到的方式破坏它。
所以，是的，选择 Beta 版，除非你想在很多用户中烧毁你的产品。
Hmmm...Beta is for a product you think is finished...until you give the Beta users to play with it and they break it in ways you haven't thought of.
So, yes, go with Beta, unless you want to burn your product on many users.
我不同意你的两个案例。
内部质量检查怎么样？ 你知道，他们也会发现错误。 仅当您没有已知的严重错误时才向客户发布测试版。
另外，一定要进行充分的测试。 如果时间紧迫并且您还没有完成所有测试，那就很难了。 不管你有没有时间，完成测试。
I disagree with both of your cases.
How about internal QA? They find bugs too, you know. Only release a beta to customers when you have no known serious bugs.
Also, always test adequately. If time is pressing and you haven't finished all your tests, then that's just tough. Finish testing, whether you have time or not.
我的答案是，有很多因素可以决定哪个更有意义：
1）错误的后果 - 如果错误会导致人们死亡，那么我认为测试版将是一个坏主意。 您能想象在核反应堆或导弹系统上运行测试版软件吗？ 另一方面，如果后果相当轻微，比如某些梦幻体育网站出现暂时中断，那么在测试版中推出可能还不错。
2）用户的期望。 想想应用程序的用户，他们对使用“测试版”的东西有何感受？ 如果这会让他们害怕实际使用该软件，并担心该软件会定期崩溃并充满错误，那么这也可能会发挥作用。
3) 应用程序的大小。 如果您要构建一个非常大的东西，比如一个 ERP 来处理 101 个国家/地区的法律要求并包含数百个附加模块，那么测试版可能比试图完成所有工作但永远无法达到您所期望的目标更合理。顾客。
4）部署。 如果您正在设置一些代码在您自己的计算机上运行并且可以轻松升级和修补的东西，那么测试版可能比试图在一开始就完成所有事情更好。
5）开发方法。 如果您采用瀑布方法，那么没有 Beta 版可能是更好的选择，而在敏捷场景中，Beta 版更有意义。 后者的原因是，在敏捷情况下，将会有多个版本随着时间的推移改进产品。
我要记住一些事情，因为在某些情况下我很容易想象使用测试版，而在其他情况下我会尽可能避免测试版。
My answer is that there are many factors that would determine which makes more sense:
1) Consequences of bugs - If bugs would result in people dying, then I think a beta would be a bad idea. Could you imagine running beta software on a nuclear reactor or on a missile system? On the other hand, if the consequence is fairly minor like if there is a temporary outage on some fantasy sports site, that may not be so bad to put out in beta.
2) Expectations of users. Think about the users of the application and how would they feel about using something that is a "beta"? If this would make them scared to actually use the software and be afraid that it is going to blow up on them regularly and be riddled with bugs, that may also play a role.
3) Size of the application. If you are going to build something very large like say an ERP to handle the legal requirements of 101 countries and contain hundreds of add on modules, then a beta may be more sound than trying to get it all done and never get to where you have customers.
4) Deployment. If you are setting up something where the code is run on your own machines and can easily be upgraded and patched, then a beta may be better than trying to get it all done right in the beginning.
5) Development methodology. If you take a waterfall approach, then no beta is likely a better option, while in an agile scenario a beta makes much more sense. The reason for the latter is that in the agile case there will be multiple releases that will improve the product over time.
Just a few things I'd keep in mind as there are some cases where I easily imagine using betas and in other cases I'd avoid betas as much as possible.
毫无疑问是测试版！
运行测试版的一些好处...
快速启动并经常迭代。
Undoubtedly beta!
Some benefits of running a beta period ...
Launch quickly and iterate often.
在不知道该应用程序是什么以及它的受众是谁的情况下，我认为这将是一个艰难的选择。 然而，如果它是一个开源项目，似乎共识通常是“尽早发布并经常发布”。
Without knowing what the app is and what it's audience will be, I think that would be a hard choice to make. However if it's an Open Source project, it seems like the consensus is usually "Release Early and Release Often".
真正的问题是：您确切知道您的用户是什么吗？
如果您回答“是”，则设计并构建所有内容并在没有 Beta 的情况下启动它。
如果您的答案是否定的，那么 Beta 版就是正确的选择 - 您的用户将帮助定义您的软件，他们会感觉更多地参与了该过程并拥有一定的所有权。
The real question is this: Do you know exactly what your users what?
If you answer yes, then design and build everything and launch it with no Beta.
If you answer no, then Beta is the way to go - your users will help define your software and they will feel more a part of the process and have some ownership.
我说贝塔。 但我不同意你的前提。 你永远不应该发布半任何软件。 作为测试版发布的软件至少应该功能完整。 这样您的用户就知道他们正在了解什么。
至于发现错误。 内部测试是最好的。 然而，任何发布过软件的人都知道，无论什么，用户都会找到一种新的、有趣的方式来破解它。
所以 Beta 版直到您满意为止。
I say Beta. But I disagree with your premise. You should never release semi-anything software. The software released as Beta should at least be feature complete. This way your users know what they're getting into.
As far as finding bugs. Internal testing is best. However, anyone that has released software knows that no matter what the user will find a new and interesting way to break it.
So Beta 'til your hearts content.
我建议首先对选定的一组（功能不完整）进行 alpha 测试，这样他们可以帮助您找到错误并确定需要哪些功能。
一旦你得到了被认为是完整的功能，然后将其发布给更大的组，主要是为了发现错误，并获得有关功能更改的评论，但除非有关键的东西，否则你可能不会进行功能更改。
此时您已准备好发布，并返回步骤 (1) 进行下一个发布。
I would suggest alpha testing first, to a select group, that is not feature complete, so they can help you find bugs and determine which features are needed.
Once you get what is thought to be feature complete, then release it to a larger group, mainly to find bugs, and to get comments on feature changes, but you may not make feature changes unless there is something critical.
At this point you are ready for release, and you go back to step (1) for the next release.
在完成（您认为的）您的软件并相信不存在严重错误后，进行 alpha 测试。 让您公司的测试人员可以使用该软件，修复报告的错误。
接下来，将软件作为 Beta 测试发布给客户，收集评论、修复错误和改进。 改进功能。
只有这样你才准备好释放。
After finishing (you think) your software, and believe that there are no serious bugs, conduct alpha testing. Make the software available within the test staffs of your company, fix the bugs reported.
Next, release the software to customers as beta testing, collect comments, fix bugs & improve features.
Only then you're ready for release.
两者都不。
在您认为产品没有错误之前，不应发布测试版。 到那时，测试版用户将会发现错误。 他们会的，相信我。 至于让测试版用户“指导设计”，可能不是一个好主意 - 您最终会得到看起来像荷马·辛普森设计的汽车的软件。 测试版用户不是软件设计师是有原因的。
至于第二个选项 - 除非您是一位出色的测试人员，否则您将无法像最终用户一样测试它（他们会对您的软件做最愚蠢的事情）。 如果你“用你给自己（或别人）的任何时间来测试它”，你将没有足够的时间。
Neither.
You shouldn't release a beta until you feel that the product is bug-free. And at that point, the beta users will find bugs. They will, trust me. As far as letting the beta users 'guide the design', probably not a good idea - you'll end up with software that'll look like the car that Homer Simpson designed. There's a reason why beta users aren't software designers.
As far as the second option - unless you are an extraordinary tester, you will not be able to test it as well as end-users (they will do the silliest things to your software). And if you "test it with whatever time you give yourself (or are given)", you will not have enough time.