Sorry, couldn't resist

You probably might as well just copy big chunks of the Alpha channel… I am sure a lot of beta questions will be dja vu :wink:

Actually, I think the beta discussions are going to be much better.

Handful of posts and I wanna just point everyone to the alpha channel already :slight_smile:

with or without beard? :slight_smile:

When a version goes beta then why not make all alpha threads into beta threads?

At least at the beginning, beta testers should be blind about the previous knowledge and discussions. They need to commit “new errors”. It’s a new fresh test. Sometimes developers even exclude alpha users from beta groups to make this experience more “pure”. Later you can add more alpha users and give access to beta users to the alpha stage data; so the alpha users could contribute explaining some decisions from the alpha stage and criticize and add more knowledge to the current beta developments.

Listening to (reading) the posts in this thread, as well as others, leads me to realize that the concepts of alpha and beta testing are no longer distinct. It seems that we have bought into the philosophy of alpha testing and extended alpha testing. Beta testing appears to be merely a second round of testing after the first round of discovered bugs have been resolved.

As a QA/Testing specialist, I have always tried (often unsuccessfully) to create a testing environment where the iterations of alpha testing are designed as finding bugs in the code. Once the code itself is reasonable complete beta testing iterations target the usability of the code, e.g. is the workflow logical/intuitive; does the program actually do what it was intended or expected to do, etc. In fact, once the initial alpha testing, and the rebuilds fixing the showstopper bugs, is completed further alpha and beta testing can continue simultaneously.

Lastly, end-user testing, while dangerous, is important since the product is built by people that typically won’t be using it. We, as engineers, often have concepts of the program that don’t hold up once the product gets out into the real world. Before we release a product we should be able to answer “Yes” to the following questions:

  1. Does the product work properly; do what it is supposed to do?
  2. Is it usable by a neophyte without hours of instructions/training?
  3. Do we know where it will break and do we know why we have decided not to fix it before the release?

Obviously question 3 cannot always be answered with certainty since no code is ever completely bug free. But if the answer is a shrug and “I don’t know.” testing isn’t complete.

For those of us who are testers or run testing groups, remember that our job is not to see if the product works; it is to find where it breaks.

The above is my opinion from over a quarter of a century in the industry (damn I feel old!). Your mileage may vary.

What I said in simple terms. :wink: https://support.google.com/googleplay/android-developer/answer/3131213?hl=en

Or you use Google’s “beta” moniker & roll it out to millions of users for 5 years and if there are issues “Hey. It’s still beta” :stuck_out_tongue:

GMail - gotta love it

Hands against the wall while we search ya kid :slight_smile:

Reality is we do tend to use very traditional notions of ALPHA (not feature complete, possibly quite buggy, may crash, etc) and BETA (feature complete but bugs may exist in those features)