Why 1.5.10 is the absolute worst version

Users who are viewing this thread

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.

In all fairness, here is what I could get from a quick research :


The first uses of the term beta can be traced back to IBM in the 1950s. According to Allan Scherr (a former IBM employee), the terminology originated during his time there. They referred to testing product ideas and theories as “A” testing and testing feature complete products as “B” testing. Over time, the “A” and “B” became “alpha” and “beta”, creating the terminology that we commonly use to this day. Since IBM was the gold standard at the time for business processes, more and more companies started to catch on to the idea of A and B testing, and thus, alpha and beta testing were born.

I think you guys might give him a point here instead of trying to save one's face on arguing.
 
Oh no, I understood. I just think your rhetoric doesn't match your intention at all, since you emphasized the definition of beta testing way too much, and I don't really agree with the premise that it's fraud, by and large. Most of the untested products we're sold aren't big productions, by volume. You can make an argument with a bigger firm like Taleworlds, which I would also disagree with, since fraud is fairly narrow in scope legally, but a single developer publishing an early access title? Those have been sprouting from the ground in massive numbers for the past few years. Intent to deceive, as opposed to necessary evil to continue production?
Now we have something to work on then. When I say it is fraud, I do it knowing that legally it is not fraud but believe me when I say the only reason it is not legally so today is because the Software development sector is not regulated enough, yet; i.e at some not-so-distant future this practice will be considered literally fraud in at least Europe. Because otherwise it is madness. I mean we are discussing games like Bannerlord which are kind of half-OK, but there are games out there which literally do not even work but people somehow sold them and got away with the money. In which other legal sector would you be able to get away such a thing?

I also know that this is common practice in gaming, pretty much everyone does it and unfortunately such malpractice has become a necessarily evil for survival especially for some companies. But for most companies out there, the only reason for not testing is maximising profits: why test a game when in the same time you can make two untested games and more than double your income? And trust me many of these companies have more than enough resources to conduct these tests; they simply choose not to because they can get away with it thanks to no regulation and uninformed customer base.

And finally, I agree that most of these companies do not do this out of "evil intensions," but if we as the customers open our eyes a bit and introduce accountability in legal terms into our relationship with game developers, we will all benefit from it. It begins with "douches" like myself (as someone called it) "ranting" about stuff; as change often does...
-----
Edit to give an example of how that accountability works outside of gaming...
As a freelance consultant in Software Engineering I have professional insurance of up to 8M euros to pay for damages that potentially might be caused by my software. Anything above that and I have to pay. My customers demand minimum coverage of 2M at least, in one case it was 5M. I have worked in sectors where the cost of an error could have been hyperbolically larger than that, including human life (hospitals.) Because I am legally accountable for my software and if something goes wrong, I have to pay for damages or even worse in the case of loss of life. This relationship is the same in B2B transactions (in fact, I count as a 1 person business.) But I also have tests, because as a good engineer I have created my tests, run them, saved reports, etc; i.e if it is not the fault of the Software that I created, it is likely that I have irrefutable technical proof for it. So the kind of accountability and testing requirements are already there in the world of Software at large, just not gaming and other popular genres where customers are not informed enough.
 
Last edited:
I think you guys might give him a point here instead of trying to save one's face on arguing.
For all I know he's completely right about it, I'm not an engineer and have no skin in this game. I just think it's all beside the point. When gaming companies use the term "beta testing" I know what to expect. In some cases I'm slightly disappointed, and in some I'm pleasantly surprised. In all cases I weigh it against the money spent and former experiences with games, and my own experiences in making them (not computer). I don't see widespread fraud, but I do see some level of incompetence or delusions of grandeur.

I mean we are discussing games like Bannerlord which are kind of half-OK, but there are games out there which literally do not even work but people somehow sold them and got away with the money. In which other legal sector would you be able to get away such a thing?
I mean, I won't argue that it doesn't exist, and maybe I'm biased due to my selection of games to begin with, but I don't know of many games that I personally considered purchasing that were scams in one way or another.

And finally, I agree that most of these companies do not do this out of "evil intensions," but if we as the customers open our eyes a bit and introduce accountability in legal terms into our relationship with game developers, we will all benefit from it. It begins with "douches" like myself (as someone called it) "ranting" about stuff; as change often does...
And I am completely on board when it comes to bigger productions, especially firms that sell games as a service. Mainly since I suspect it will only slightly affect the bottom line and improve quality immensely. But any regulation needs to address the fact that a huge bulk of the industry are still just barely above the level of amateurs trying to create something enjoyable. If the Rise to Ruins guy were forced to employ professional tier testing or face legal ramifications the game would be a pipe-dream.
 
Last edited:
But any regulation needs to address the fact that a huge bulk of the industry are still just barely above the level of amateurs trying to create something enjoyable. If the Rise to Ruins guy were forced to employ professional tier testing or face legal ramifications the game would be a pipe-dream.
Sure, regulations can always give some leeway to solo devs or very little studios with a demonstrable lack of resources. I am not an engineering-fascist :smile: or, perhaps I am; but in this case I just want people to be honest about their work and test it properly.
 
That's funny because while making a coffee break I came across a reddit thread debating the issues regarding some AAA games, most importantly on a engineering perspective rather than financial/marketing etc..

I think this is relevant here, here is the quote :

I think your comment highlights quite a common issue; most people (including developers) don't actually know what alpha and beta mean.

Alpha is a state where a product is functional but feature incomplete. Yes there will be bugs, often quite serious, and in terms of games you'll have placeholders for textures, models, animations, etc. but it will still be "playable".

Beta is a state where the product is feature complete. It's finished. All that remains is final bug testing which, again, means that there will be some serious bugs but the product should be usable.

Obviously, nowadays developers have bastardised these terms so that the general public think that they are equivalent to pre-production and pre-alpha respectively. "Early Access" has only muddied the waters further.
 
That's funny because while making a coffee break I came across a reddit thread debating the issues regarding some AAA games, most importantly on a engineering perspective rather than financial/marketing etc..

I think this is relevant here, here is the quote :
Thanks for sharing. Now I know I am not alone :smile:

My only criticism would be the part where he says "final bug testing" but obviously should have called it acceptance (or user) testing. Most (business) customers are not be happy with buggy betas and they cancel acceptance altogether in such cases (i.e reject the product.) And as I described earlier most bugs do not even survive various layers of tests you run against your system.
It's "beta"
I see what you did there :smile:
 
Last edited:
In all fairness, here is what I could get from a quick research :

"They referred to testing product ideas and theories as “A” testing and testing feature complete products as “B” testing."

I think you guys might give him a point here instead of trying to save one's face on arguing.
Feature completeness usually refers to the existence of features, not "bug free"-ness. If we're referring to ISO 25010 Standard of Software Quality as our Software Quality Model (and there are MANY software quality models out there), errors and bugs tie to "Feature correctness" not "Feature completeness" which is another sub-characteristic under the same parent. Of course, you know about this according to your later post from reddit, which pretty much confirms he's wrong ("there will be some serious bugs").

I'm not saving face on arguing. I'm not the one getting his ass blown open in public. I'm teaching an arrogant know-it-all self-proclaimed expert a lesson in humility. The scope of human knowledge is extremely vast, and there are many experts saying different things, most of which are respectable bits of knowledge. You can never be so sure about the little bits you have, and that's why people should be polite and respectful. IT is an especially broad and fast-evolving field of expertise notorious for unclear and broad definitions. Acting like a prick flaunting petty small knowledge is a clear sign of ignorance.

And why am I doing this? Because I never got the chance to publicly humiliate someone when I was a teacher. None of my students acted like a smartass in my class.

You are essentially an ignorant who looked up technical definitions somewhere and thought he understood them all now;
They're technical definitions from the very glossary you referenced. Did you not know this because you only Googled up the beta definition and copied it without looking at the rest of the glossary?

In your little mind, you already understand Alpha/Beta testing because these two definitions already cover everything.
You started this whole thing by dissing someone because you think what he said doesn't fit the one definition from IBM you knew, which you failed to quote yourself and had to resort to another glossary, which you failed to read. I have said multiple times that there are many definitions of beta testing, but again, you suck at reading and it shows.

And here's the funny thing. None of the things you mentioned proved your point that an application should be free of bugs when they're out of alpha. You can keep throwing other definitions and theories to distract people and conjure up an image of competence, but it's not going to work on me because I actually know these stuff. If you fail at conforming to definitions you pulled yourself, it's just embarrassing and even people who don't dabble in this field know that.
 
Last edited:
I think this is relevant here, here is the quote :
I guess we're back here now:
I think your comment highlights quite a common issue; most people (including developers) don't actually know what alpha and beta mean.
This is the exact problem I'm referring to rehashed again. You can argue that the standard for beta testing should be universally returned to the standard set by IBM, that according to you it should mean something different, but it makes no sense whatsoever to tell the majority that they don't know the meaning of a term when the majority decides the meaning, and it works in conveying that meaning. For most of humanity it doesn't mean what it means to you. The poster could have written:"most people (including developers) don't actually know what alpha or beta were supposed to mean"

You have two choices to influence things in a way that you think is beneficial: either concentrate on getting the standards within the industry up to par, or you can try to forbid game developers and players from using the popular term, since they're apparently "wrong".

I suspect the latter is hard or nigh on impossible, wouldn't further your goals (since I doubt anyone cares what term they can call their unfinished, untested version), and ultimately futile and unproductive.

To be more specific, legislating that companies may not advertise their products as beta tests makes no sense whatsoever, while legislating that every product of a company with more than 100 employees has to fulfill the formal requirements for beta testing established by X might have an effect. This effect will in turn alter the way beta testing is used to be more in line with whatever the formal requirements are.

It doesn't even really matter how it got to that point of "bastardised" meaning, be it ignorance, a popular song lyric or a concerted effort to undermine engineering terminology, only that it did. This focus on "other definitions of beta testing are wrong" does not work in anyone's favor, while "products aren't tested enough" is a statement with substance.
 
I just want to thank you all for derailing my thread and making it my most viewed post ever.

Also, electron is specifically defined and as of now, there are no schisms in the science community on this issue, whereas beta has not, is not and will most probably never get a specific definition that's acceptable to everyone or even the majority.
 
I just want to thank you all for derailing my thread and making it my most viewed post ever.

Also, electron is specifically defined and as of now, there are no schisms in the science community on this issue, whereas beta has not, is not and will most probably never get a specific definition that's acceptable to everyone or even the majority.
I already quoted a definition from the most trusted source I could find. It is pretty much well-defined for the technical reasons I wrote about. The technical argument, of course, is only as strong as your capacity to understand the technical requirements of testing. Just call it whatever you want at this point.
They're technical definitions from the very glossary you referenced. Did you not know this because you only Googled up the beta definition and copied it without looking at the rest of the glossary?


You started this whole thing by dissing someone because you think what he said doesn't fit the one definition from IBM you knew, which you failed to quote yourself and had to resort to another glossary, which you failed to read. I have said multiple times that there are many definitions of beta testing, but again, you suck at reading and it shows.

And here's the funny thing. None of the things you mentioned proved your point that an application should be free of bugs when they're out of alpha. You can keep throwing other definitions and theories to distract people and conjure up an image of competence, but it's not going to work on me because I actually know these stuff. If you fail at conforming to definitions you pulled yourself, it's just embarrassing and even people who don't dabble in this field know that.
I never said "completely free of bugs", I said "mostly" free of bugs... As in; the final rope you are trying to hold on to was never even there. And that should be the end of it. Again, you are an idiot who though two sentences per definition from a glossary helped you understand the topic. Why don't you read the whole glossary and proclaim yourself a test engineer, then? What a f*ing child... :smile:

Edit: I would like to see you read a two sentence definition of quantum physics and try to debate a physicist.
 
Last edited:
I said "mostly" free of bugs.
Which is still not true, even by the source you referenced. Not only there's no such specification in the definition (in fact other sources speak to the contrary), what falls within the definition of a bug is very wide (even a tiny flaw counts), and there's no clear metric on at what point is a software "mostly" free of bugs.

This little game you're doing is very easy to read. You barge in on this kind of threads insulting the devs (and looking down on others) to boost your own ego, flaunting cranked up ideals and theories like they're something mandatory. People who do this are usually fresh-graduate academics who have little to no dev experience and can't code beyond basic functionalities. That's why they flaunt theories instead, because they have nothing else to contribute. They don't know that the industry is run on tight schedules and cut corners, because they've never been in the trench.
 
Which is still not true, even by the source you referenced. Not only there's no such specification in the definition (in fact other sources speak to the contrary), what falls within the definition of a bug is very wide (even a tiny flaw counts), and there's no clear metric on at what point is a software "mostly" free of bugs.

This little game you're doing is very easy to read. You barge in on this kind of threads insulting the devs (and looking down on others) to boost your own ego, flaunting cranked up ideals and theories like they're something mandatory. People who do this are usually fresh-graduate academics who have little to no dev experience and can't code beyond basic functionalities. That's why they flaunt theories instead, because they have nothing else to contribute. They don't know that the industry is run on tight schedules and cut corners, because they've never been in the trench.
Why do you speculate so much about me and my credentials?
My linked in profile: https://www.linkedin.com/in/mehmeteking/
 
I really didn't have to speculate as it is irrelevant. What are you even trying to do by sharing your profile? To prove the nonsense you've spouted was right, or to justify your demeaning attitude?
Wow, that's really rich. Attack my credentials without knowing about them and cry foul when they are exposed. I shared it because you forced my hand.

As to "nonsense" that I spewed, I already explained in technical terms what I am talking about; you are just unaware of the fundamental principles of software engineering and thought reading couple sentences per term gave you any right to debate them. At the end of the day, you are far less intelligent than you think; and do not even understand when he is defeated. Which should not be surprising, after all you brought a switchblade to a tank battle and thought that would work.
 
I shared it because you forced my hand.
Your ego did, not me.

What you said didn't even fit the definition you referenced. Bugs will be found and fixed in beta testing. Nothing you have brought so far proved that wrong. You want to be technical about terminology? Then bring up valid sources and compare enough of them to make a conclusion. That's how you do it. You failed to bring your first reference, and if that wasn't embarrassing enough, the replacement reference you brought proved you wrong. You can keep calling other people idiots if that's all you can do, but it doesn't help your argument at all.
 
What you said didn't even fit the definition you referenced. Bugs will be found and fixed in beta testing. Nothing you have brought so far proved that wrong. You want to be technical about terminology? Then bring up valid sources and compare enough of them to make a conclusion. That's how you do it. You failed to bring your first reference, and if that wasn't embarrassing enough, the replacement reference you brought proved you wrong. You can keep calling other people idiots if that's all you can do, but it doesn't help your argument at all.
So you are telling me that Software Validation can equate Software Verification because I have no source to say otherwise? I explained already what they are. You did not even get it. That's it. Go to sleep now.

Edit:
This little game you're doing is very easy to read. You barge in on this kind of threads insulting the devs (and looking down on others) to boost your own ego, flaunting cranked up ideals and theories like they're something mandatory. People who do this are usually fresh-graduate academics who have little to no dev experience and can't code beyond basic functionalities. That's why they flaunt theories instead, because they have nothing else to contribute. They don't know that the industry is run on tight schedules and cut corners, because they've never been in the trench.
Your ego did, not me.
Just f*ing be honest about what you did at least. If is documented ffs.
 
Last edited:
So you are telling me that Software Validation can equate Software Verification because I have no source to say otherwise?
I didn't even mention software validation or software verification, so good job on putting words in my mouth in an attempt to derail the conversation. All I've asked of you is to prove your idea that a software product "should be more or less bug-free when it reaches Beta stage." Your mention of software validation and software verification are pretty much irrelevant because bugs are not limited to programming or technical errors that can be detected by automatons. An inaccurate result, unintended behavior, or a technically correct behavior that is wrong according to the business process, fall within the definition of a bug.

defect
Ref: After IEEE 1044
Synonyms: bug , fault
An imperfection or deficiency in a work product where it does not meet its requirements or specifications.

Standard Glossary of Terms used in Software Testing Version 3.2 - International Software Testing Qualifications Board
Many of such bugs can only be found after the product is used by more users, and in their environment, which is what beta testing is.

Edit: I want to apologize to the community for keeping to engage in this derailment. Feel free to smack me if necessary.
 
Back
Top Bottom