I have responded in-depth to your posts before, but you're a senior engineer talking about linguistic phenomena and consistently confusing opinion for fact (i.e.: Terminology within specific fields have universally accepted definitions that are inherently unchangeable unless some authority within said field says otherwise, especially relating to usage outside of said field).
I am not confusing it, you are! And that has been my whole point
Gaming companies sell "beta testing" as a form of testing and everyone here is buying it. It is only a form of "acceptance testing" which is not formal, structured, etc; i.e. not development testing!
I could even agree with the gist of your point: Maybe they should call it banana testing to respect the feelings of engineers far and wide, but the industry and consumerbase as a whole has settled on selling us non-beta open beta's,
Yes, again exactly my point, Thank You! The industry (snake oil sellers) has settled on selling the consumbase (snake oil buyers) on selling non-beta open betas. Well said. And I speak against it, so what? Swimming against the current but I already told you that is what I do by nature. Cant help that.
Hahahahhahaa.... (literally lolled though)
and nobody cares about anything besides the end product.
The one that works, right?
So unless there's a populistic upheaval of humanity focused on renaming early access game releases, calling games a beta will be colloquially understood to mean whatever a game company puts out before they think it is finished.
No, it is the same as saying "there will always be snake oil salesmen" which is historically false
Customers get smarter and fraud schemes get old.
And I certainly am not judging a whole discussion from a "last line", but being unpleasant won't help you getting your point across.
I am sorry about all the unpleasantries. Let's just say I am "socially challenged."
Regarding your cute edit:
There are thousands of examples where exactly this has happened. Ethics boards have decided that terminology isn't appropriate due to a change of public perception and/or use, so a different term has been adopted within the field. This is especially obvious when it comes to terminology of disabilities.
If you look at my posts, you will find that everytime I said or implied "if terminology changes it happens through the discipline." You gave us another fine example of exactly what I am talking about.
Oh my. Then I wonder where did you pull that definition from. Your ass?
But to your credit you managed to pull something. Let's discuss that source then. I'll be generous and just discuss that specific source and not cross-check it with other definitions by other experts or literatures. I'll even ignore the newer version of that glossary. Let's see.
Now for context, let's pull the definition of alpha testing first, because to quote you, "Alpha testing should already have validated the software, i.e. it should be more or less bug-free when it reaches Beta stage."
See, the difference between alpha and beta lies in the site of the test and the population (which checks out with one of my previous posts), and has no specifics on whether or not the product should be "bug-free when it reaches beta stage." It actually refers to the same thing, acceptance testing, which we will discuss after dissecting this definition.
"Whether or not the system satisfies the user needs and fits the business process." Now let's take an example of the bug mentioned in the OP. Inability to give commands after battle. Does that satisfy the user needs? Nope. Neither would crashes and other bugs or errors. I'll refer to "Functional Suitability" from ISO 25010 for this particular quality. A bug or error violates the sub-characteristic "Functional Correctness" of "Functional Suitability". Now let's look back at the glossary. According to the definition of beta testing, it is where we handle this, so you're wrong.
Now let's move on to acceptance testing. Again, referring to the very same glossary you mentioned, let's look at the definition.
Pretty much the same thing except for the mention of acceptance criteria, which is defined as:
Now, where is the part which says that finding bugs and fixing them is not part of beta testing? Try to be polite this time. Save yourself the embarrassment.
Edit: It's 1AM where I live, so take your time pulling whatever you want to pull. I'm going to sleep.
Sorry, but you are not worth further discussion.
Edit: Couldn't keep it inside.
You are essentially an ignorant who looked up technical definitions somewhere and thought he understood them all now; while both naturally and demonstrably understanding
none of them. In your little mind, you already understand Alpha/Beta testing because these two definitions already cover everything. Right? If Alpha testing is nothing more than what that definition says, and the same with Beta testing; and since you understand both you are ready to take on any testing project! Genius!
Software Verification is the process we call "development testing", or more commonly just "testing" in the field. This process is called "Alpha Testing" in the Alpha/Beta testing methodology.
Alpha testing covers all kinds of formal tests under the general categories (or layers) of
unit tests,
integration tests and
system tests. The latter is often quite rich as it also covers
end-to-end type tests as well as
non-functional tests. The defining quality of these
formal tests are that they are
automated,
repeatable, determinant, structured, documented,
unopinionated etc. and they
test only
their respective subject. These tests also serve as constraints for builds, branch merges, etc. Informal tests can also be included in this phase of development, the most common practice for that being s
taging. Therefore a system is covered by at least three layers of tests each spanning the entire system
at least once, not counting the informal tests. My customers are often large businesses, but I have never seen any of them either deliver or buy untested software for doing so comes with legal repercussions and other risks. Us peasants, on the other hand...
Software Validation is the process of integrating software into its environment and making sure it answers customer requirements, its manifestation we call "acceptance tests." They are not formal; in fact, how they are carried out is only the customers business. They are also
not automated, repeatable, determinant, structured, documented or unopininated (haha.) Therefore acceptance testing, which is what we call "beta phase" in Alpha/Beta testing is actually an approval stage. The "test" in the name comes from the assumption that the customer will have its own formal tests for accepting the product, which is exactly what businesses also do.
Therefore the difference between Alpha and Beta testing is bit more than, what was it? "Population"? Hhahaha... Don't you realise that if these definitions would allow you understand these terms enough to be able to make comparisons between them, that "glossary" would have to be a large encyclopedia? Like, how is it that I am the one telling you this and you cannot figure it out yourself?
Again, for the final time: Beta testing cannot go beyond its definition and cannot be considered formal testing because there are severe technical limitations for it, several of which I have written above. It is just an approval stage simply because it has literally nothing to do with the principles of Software Testing. Hope you and others get a better picture now.
