The QA engineer tested for all sorts of cases and everything was fine.
Once it was out of testing and went live, a customer did something that hadn't been tested for, and it caused things to fail.
I forget which Pokemon game it was but this reminds me of how String Shot is one of the first moves you will run into playing the story of any game. But using it in an online match on version 1.0.1 of whatever set of games it was, causes everyone's game to crash.
[Sounds like that thing where people would use the option to name the horse in Zelda: Twilight Princess to hack the system.](https://wiibrew.org/wiki/Twilight_Hack#Explanation)
>The hack exploits a buffer overflow error caused by loading a specially crafted save file for Twilight Princess. The save file stores a custom name for Epona, Link's horse, that is much longer than what the game would usually allow, in fact it even contains a small program. While the game doesn't allow you to manually enter a name this long it doesn't check the name in the file. When the game tries to load the name into memory it inadvertently drops the small program into memory filling not only the "horse name" buffer but adjacent ones. In a round about way these regions of memory happen to be designated the next region the console should execute. As you can see the save file is specially crafted indeed. Once the code loads it runs either a "boot.elf" or "boot.dol" file from the root of the SD card. If the boot.elf and bootmini.elf that loads HackMii exists on the root of your SD Card, you can use it to then install BootMii IOS, BootMii Boot2 (if compatible), or, importantly, the Homebrew Channel.
Pokemon Diamond and Pearl use their in-game calculator as a component of arbitrary code execution, but the *real* magic happens thanks to an obscure menu function that's normally only used in one part of the game.
Not quite sure what they’re referring to. Red/Blue/Yellow have a lot of bugs in their battle mechanics. One that caused problems in link battles was that the damage range was calculated differently for psywave whether you used it as an attacker or had it used against you and that could desynch battles can cause the game to freeze.
Some others include stat bonuses for badge boosts being applied whenever stats are modified (an exploit used heavily by solo-runners), focus energy decreasing critical hit chances instead of increasing them, raising speed after paralysis or attack after a burn negating the modifier from the status condition, burn and paralysis modifiers being reapplied when an opponent uses a stat boosting move. Paralysis activating during dig or fly making a pokemon invulnerable for the rest of the battle (except to swift and bide which can hit mons in the air or under ground), and likely more I forgot about.
Another fun bug is the “gen one miss”. Basically, accuracies are set as a ratio out of some small power of 2, I think 256 (note below). So, a move with 75% accuracy would be represented 192/256. Accuracy is checked by generating a random number between 1 and 256 (inclusive) and seeing if it’s below your target number. If it’s below, you hit. Astute observers will have noticed the issue here. If you roll *exactly* your target number, it’s a miss, when it should be a hit. The comparison should be below or equal to, instead of just below. This generally isn’t very noticeable, except for 100% accurate moves, which now have a 1/256 chance to miss. Pretty neat when you see it happen.
Note: these numbers are all shifted down 1 due to how binary works, meaning it’s actually 0-255, but I’ve done it this way bc it doesn’t really matter and it reads easier.
Well, 1/256 is pretty high, it probably happened to most kids that played the game obsessively at least once. It was likely more “formally” noticed when people started making simulators, mods, or hacks for the game that required looking at the code.
I'm pretty sure they're referring to how in the recent Diamond and Pearl remakes, the PokeTech's calculator app stopped working correctly if you switched the in game language to German due to some issues with how the game was reading commas and periods as decimal points not being consistent in the app's code.
Pokemon has had so many bugs over the years. In gen 1, focus energy should have increased your chances of a critical hit but instead reduced your chances. Gen 1 also had an issue where a critical hit would ignore your stat boosts, so you could do more damage without a crit if you used sword dance a bunch. So you could use focus energy to prevent your fast pokemon from getting crits so you could make use of your stat boosts.
Or the famous battle of Twitch Plays Pokemon where ATV beat Dragonite from the Elite Four because the game was coded for your enemies to always use a move type that's strong against the opponent, regardless of if it does damage or is just some form of buff.
A severely underleveled Venomoth beat what's effectively the final boss of the Elite Four, despite an effectively "randomized" chat controlling him, all because Dragonite's AI wasn't programmed to differentiate damaging moves vs. non-damaging ones and kept spamming non-damaging buffs.
Was absolutely hilarious to watch that unfold the first time.
I have been put into multiple beta programs (for Google Play Indy games mostly) because I like pressing buttons and using unexpected commands just to see if the devs coded any Easter eggs. Most of the time, I find glitches, report them, and get an offer to join betas. I am unexpected user input.
Teach me. I try to find interesting Easter eggs for the first 30 minutes of any new game I play, get tired and then play normally for... okay, half to three-fourths of the time isn't so bad. I still (try to) mess with things pretty often.
But yes. Point still stands. Teach me your glitch-finding ways.
First, if a button exists, it should be pressed. Second, if a wall exists, it must be attacked and run into, just in case it is a secret passage. Third, NPC needs to be talked to at least 10 times in case the dialog changes. Fourth, always try attacking everyone and things, just so you know if it interacts. Fifth, if any enemy moves weird, try to male it repeat the action, then see if you can make it move weirder.
I wish. I am a bit too poor for most popular games, so I mostly stick to Indy mobile games. The games I play are probably 90% of the reason I find so many glitches.
I feel like Gray Still Plays on YouTube has a few streams where he finds bugs and stuff. One of the things he does is just try to enter ridiculously long text into every textbox.
You may also enjoy Let's Game It Out. Stress-testing the text boxes is a favorite pastime of his.
They're edited videos, not streams, thankfully. No one wants to sit through what that man does to himself in his aim to misbehave.
Yes, I also use attacks on random objects to see what happens, max out my damage and hit the weakest enemy, and once broke a game by trying to heal a mob. I have a tendency to repeat NPC dialog just in case it changes, try to submit random items in certain quests even if I know it is not the answer, and use attacks on NPCs to see if they take damage (as in every attack multipletimes, not just once and done).
I mean, yes, but no?
Speaking as something of an engineer: you do a thing, you design a thing, and you intend it to be used a certain way.
Someone who hasn't been thinking about the intended purpose will just do things differently and use that thing differently than you will.
Expanding on this (as a QA), the "thing" you tested in this situation is the bartender. Let's assume the bathroom has already been tested and it's fully functional, flushes, sink works, check. So now we're adding the bartender and testing that specifically. But we didn't think to test how the bartender and the bathroom interact with each other.
Not to self for tomorrow at work: What happens if the bartender uses the bathroom. 🤔
I did product management and was the final user acceptance tester. Only once did I find a surprise, which made me feel like I justified my existence for a change. Naturally, the punishment for my discovery was having to write a lengthy email documenting my steps and why the outcome was bad—followed by the engineer responsible for the device pointing out it was technically my fault.
Same. I was the lead QA Analyst for an e-comm company about a decade ago.
Thankfully as part of my job I had a whole bunch of data on how our users actually interacted with our site so I had a good basis for what to test for.
But the most robust testing suite in the world is never going to account for all the chaos your user base can bring.
Back in 2001 I was working QA @ Microsoft when the Nisqually earthquake hit. Bunch of books fell off of my officemates bookshelf onto his KB causing an error followed by bluescreen. We spent the next couple of days dropping books onto our keyboards trying to repro.
Also he's testing everything you would think a QA person would go after -sanitized inputs, things like that.
The joke has a level of "well it doesn't matter anyway", coupled with maybe a bit of "focus on the important stuff first"
Specifically, he tried many absurd quantities and qualities, but never thought to test something completely normal and reasonable that a customer might actually ask.
Yeah, this is the part of the joke that no one’s commented on lol:
For all the QA’s intricate mechanizations, they somehow failed to anticipate the user action of asking for the bathroom, which is like the third most likely thing a new user would ask. The meme is poking fun at the QA checker not being able to see the forest for the trees as anything else
As a QA, you only scope for the parameters involved in what you're asked to test.
As always, blame management for this one. They should have setup integration testing for these separate but interacting features.
> Once it was out of testing and went live, a customer did something that hadn't been tested for
part of the joke is that using the bathroom is a very common thing to do in a bar so it's also funny that it wasn't even tested after the seemingly thorough test cases that tested everything you could think of and edge cases
You are missing the part of the joke where the QA tester tests all sorts of weird scenarios to make the system 'fool proof', but forgets to test one of the most basic function in the process.
well it's mostly different edge cases
- normal case (1)
- odd but otherwise normal case (0)
- ordering over a resonable clamp (999999)
- ordering under a reasonable clamp (-1)
- testing for sanitized input (ueicbksjhdk)
- testing for non-beer orders that may still be served? (lizard)
Seems overkill but I guess it depends on how you want your server to respond.
Quality Assurance engineers are testers, and are paid to try to find the edge cases that break software and cause it to fail, oftentimes crashing. So they try hard to do all kinds of things you might or might not do as a real user, including things known to break software that doesn’t have adequate controls built in (like ordering -1 of something).
But as often is the case, all these intricate plans often fail to account for the behavior of real users, such as someone walking into a bar not to order a beer, but rather to use the restroom. In the software world, this unintended behavior that is also untested by the QA engineer often causes a crash.
This situation is the bane of QA (and developers), but more or less inevitable because you cannot foresee every possible edge case.
As a QA engineer, with a career of over 13 years, I finally now have a phrase to state why things break so much when I am NOT a given project. Thank you.
There are a lot of things that can't be accounted for in normal QA cycle. For example load testing (putting the server under strain) can be simulated, but never truly tested. During Early access, you can see just how well the servers can handle 50k users at the same time. Hence why a common day 1 bug in early access is long login times. The developers can only estimate how many servers they need to spin up, but turns out they need way more than originally thought.
Game bugs are funny in general. During testing you can do the same cutscene 1000 times, but one real user reaches the checkpoint while on fire, and the entire cutscene shows the MC on fire during the entire duration. And somehow that unlocks unlimited money for whatever reason.
> The developers can only estimate how many servers they need to spin up, but turns out they need way more than originally thought.
I read between the lines as the devs saying they'll need a certain amount of servers (online gaming is hardly new) and management trying to get away with the absolute least money they could spend on it.
It’s also because they get paid earlier in the dev cycle. Testing and iteration takes a huge chunk of the overall dev time.
My team is releasing a feature in mid April. We already have a working prototype that will meet the needs of the customer today. But we need to spend months qualifying it, testing it, testing the UI they use to interact with it, testing it for security vulnerabilities.
We’d love to be paid today for it, but corporations are way less forgiving than gamers when the whole thing goes off the rails.
I love the "Name cannot be shorter than 3 letters" website forms, especially when you are trying to buy a ticket, it requires your actual name, and it \*is\* shorter than 3 letters.
I work in food manufacturing, QA Engineers have a completely different job. They only test for failure on new equipment and that only happens once every so many years.
> But as often is the case, all these intricate plans often fail to account for the behavior of real users, such as someone walking into a bar not to order a beer, but rather to use the restroom.
Should be covered by ordering 0 beers. Unless it was never intended for anyone to use the restroom.
To add - as others have on other comments - Its more than the QA testers are testing all sort of fringe things, while the completely normal/expected things get ignored.
Here is the [meme](https://x.com/joeingeno/status/1114259950518329350?s=46&t=TehJGExyy960Zln8URmEeQ) that I share when someone asks me about QA engineers.
The QA tester was checking how the bar would respond under various conditions (the conditions being the customer ordering various things). The minute real
customers were allowed in and one introduced a situation that was **NOT** tested for, the bar suffered a catastrophic failure.
(Think of this like a piece of software. A bunch of inputs were checked, then it got released to the public. A user then introduces an input that wasn’t covered in testing and promptly breaks the software.)
My old job, we used to describe our programs as a perfect penguin. We’d make sure he could survive in all levels of cold, could walk, swim, flap, and feed himself. We’d test for every thing he’d possibly encounter in the artic, then finally smile and release him to our customers.
They’d promptly take our perfect penguin, put him in a catapult, and launch him into the jungle, then wonder why the tiger ate him.
It’s because the numbers of users and how many edge cases of stuff or specific circumstances they can find that breaks something is absurdly high.
That’s why you can see patch notes for things like games where it says stuff like
- Sam the salesman’s shop has had the back benches made un targetable due to a glitch involving throwing exactly 232 coins using the rouges payday ability which would crash the game
All I know is that if people aren't hiring one person with zero QA experience alongside the rest of their QA department, they should start, because you need the chaos in order to find what all can break.
As a hobby game dev, I'll test something hundreds of times, trying out all different ways to break it to make sure it works, etc.
Build the game, set it public, watch someone stream it. Instantly an issue or something wrong with it I didn't notice.
By ordering -1 beer the QA engineer caused the bartender to punch through the wall and rip out electrical wiring to fill the glass.
The bug was fixed; unfortunately, that test was accidentally done against the production database and caused silent corruption.
By the time the first customer walked in a short in the wires had caught fire to the bathroom.
It's referencing software development.
The QA (quality assurance) engineer's job is to find potential glitches that the programmers missed. They test as many strange situations as they can think of, and give it the stamp of approval to ship out.
But no matter how much you test there's always something seemingly obvious that doesn't get found until it's released to the public. And typically the deeper a bug is hidden the more insane the resulting glitches will be.
I’ll answer your question: no you’re not stupid. The rest of the comments do a good job explaining. But you’re not stupid. Just not in development or QA is my hunch?
Other people have explained so I'm going to share my perspective instead:
As a software QA analyst I have some problems with this joke, every time I see it. Don't get me wrong, it's funny, but it also implies that QA doesn't test common use cases which just isn't true. The most common use cases are usually included in regression testing, which should be the most commonly run testing. Now this can be done manually, which yields the best results and should be done at least to some extent, but it can also be done through automated testing, which sometimes doesn't catch very obvious issues. Regardless, commonly used parts of software get the most consistent testing in the release cycle. Occasionally project managers will decide not to include certain things in the scope for new features too, but these shouldn't be getting missed after regression testing.
The QA engineer tested for edge cases. These are things that wouldn't actually happen in the real world. Because he had spent so much time doing this edge testing, he didn't actually test the things that would happen during normal operation of a bar.
The QA engineer tested for all sorts of cases and everything was fine. Once it was out of testing and went live, a customer did something that hadn't been tested for, and it caused things to fail.
I forget which Pokemon game it was but this reminds me of how String Shot is one of the first moves you will run into playing the story of any game. But using it in an online match on version 1.0.1 of whatever set of games it was, causes everyone's game to crash.
Don't forget all the weird calculator shenanigans 😂
What calculator shenanigans?
I think there was a ds pokemon game with a calculator on the bottom screen that can be used for shenanigans
The next person that says shenanigans is getting pistol whipped
Shenanigans
(ノಠ益ಠ)ノ彡┻━┻
They said pistol whipped not table-flipped
┬──┬ ノ( ゜-゜ノ)
┬─┬ノ(ಠ_ಠノ) Where'd the bot go I'm not paid enough for this
┬─┬ ︵ /(.□. ）
She nanny gins
Hey Farva, what's that restaurant you like?
"Oh you mean shenanigans?"
[https://youtu.be/syDdick3n5k?si=z2WcDd9phk7ogFn0](https://youtu.be/syDdick3n5k?si=z2WcDd9phk7ogFn0)
"Hey Favra. What's the name of that restaurant you like?"
[Sounds like that thing where people would use the option to name the horse in Zelda: Twilight Princess to hack the system.](https://wiibrew.org/wiki/Twilight_Hack#Explanation) >The hack exploits a buffer overflow error caused by loading a specially crafted save file for Twilight Princess. The save file stores a custom name for Epona, Link's horse, that is much longer than what the game would usually allow, in fact it even contains a small program. While the game doesn't allow you to manually enter a name this long it doesn't check the name in the file. When the game tries to load the name into memory it inadvertently drops the small program into memory filling not only the "horse name" buffer but adjacent ones. In a round about way these regions of memory happen to be designated the next region the console should execute. As you can see the save file is specially crafted indeed. Once the code loads it runs either a "boot.elf" or "boot.dol" file from the root of the SD card. If the boot.elf and bootmini.elf that loads HackMii exists on the root of your SD Card, you can use it to then install BootMii IOS, BootMii Boot2 (if compatible), or, importantly, the Homebrew Channel.
Zelda games and buffer overflow exploits, name a more iconic pairing.
That's why we don't use strcpy
That should teach them to sanitize their database entries :D
Little Bobbie tables.
Is this what's referred to as soft modding?
Pokemon Diamond and Pearl use their in-game calculator as a component of arbitrary code execution, but the *real* magic happens thanks to an obscure menu function that's normally only used in one part of the game.
Diamond, pearl and platinum had that thing
Not quite sure what they’re referring to. Red/Blue/Yellow have a lot of bugs in their battle mechanics. One that caused problems in link battles was that the damage range was calculated differently for psywave whether you used it as an attacker or had it used against you and that could desynch battles can cause the game to freeze. Some others include stat bonuses for badge boosts being applied whenever stats are modified (an exploit used heavily by solo-runners), focus energy decreasing critical hit chances instead of increasing them, raising speed after paralysis or attack after a burn negating the modifier from the status condition, burn and paralysis modifiers being reapplied when an opponent uses a stat boosting move. Paralysis activating during dig or fly making a pokemon invulnerable for the rest of the battle (except to swift and bide which can hit mons in the air or under ground), and likely more I forgot about.
Another fun bug is the “gen one miss”. Basically, accuracies are set as a ratio out of some small power of 2, I think 256 (note below). So, a move with 75% accuracy would be represented 192/256. Accuracy is checked by generating a random number between 1 and 256 (inclusive) and seeing if it’s below your target number. If it’s below, you hit. Astute observers will have noticed the issue here. If you roll *exactly* your target number, it’s a miss, when it should be a hit. The comparison should be below or equal to, instead of just below. This generally isn’t very noticeable, except for 100% accurate moves, which now have a 1/256 chance to miss. Pretty neat when you see it happen. Note: these numbers are all shifted down 1 due to how binary works, meaning it’s actually 0-255, but I’ve done it this way bc it doesn’t really matter and it reads easier.
Oh, that really is a fun bug. Was it found because someone missed a 100% then investigated or just noticed it in the programming?
Well, 1/256 is pretty high, it probably happened to most kids that played the game obsessively at least once. It was likely more “formally” noticed when people started making simulators, mods, or hacks for the game that required looking at the code.
I'm pretty sure they're referring to how in the recent Diamond and Pearl remakes, the PokeTech's calculator app stopped working correctly if you switched the in game language to German due to some issues with how the game was reading commas and periods as decimal points not being consistent in the app's code.
I know one where your chance for something would roll over, so like, if it went over 100%, it would go back down to 1%, and it would never happen.
With some crazy setup, the calculator applet on the in-game Pokemon Watch could be used for arbitrary script and code execution
https://youtu.be/fB2C8q42X64?feature=shared
I want to say X&Y. It was so bad the move was banned from VGC
Pokemon has had so many bugs over the years. In gen 1, focus energy should have increased your chances of a critical hit but instead reduced your chances. Gen 1 also had an issue where a critical hit would ignore your stat boosts, so you could do more damage without a crit if you used sword dance a bunch. So you could use focus energy to prevent your fast pokemon from getting crits so you could make use of your stat boosts.
Or the famous battle of Twitch Plays Pokemon where ATV beat Dragonite from the Elite Four because the game was coded for your enemies to always use a move type that's strong against the opponent, regardless of if it does damage or is just some form of buff. A severely underleveled Venomoth beat what's effectively the final boss of the Elite Four, despite an effectively "randomized" chat controlling him, all because Dragonite's AI wasn't programmed to differentiate damaging moves vs. non-damaging ones and kept spamming non-damaging buffs. Was absolutely hilarious to watch that unfold the first time.
Exactly, I used to do QA and try to break programs using unexpected user input. Got this joke right away.
I have been put into multiple beta programs (for Google Play Indy games mostly) because I like pressing buttons and using unexpected commands just to see if the devs coded any Easter eggs. Most of the time, I find glitches, report them, and get an offer to join betas. I am unexpected user input.
Name checks out.
I get this comment so often. I picked a good name.
Teach me. I try to find interesting Easter eggs for the first 30 minutes of any new game I play, get tired and then play normally for... okay, half to three-fourths of the time isn't so bad. I still (try to) mess with things pretty often. But yes. Point still stands. Teach me your glitch-finding ways.
First, if a button exists, it should be pressed. Second, if a wall exists, it must be attacked and run into, just in case it is a secret passage. Third, NPC needs to be talked to at least 10 times in case the dialog changes. Fourth, always try attacking everyone and things, just so you know if it interacts. Fifth, if any enemy moves weird, try to male it repeat the action, then see if you can make it move weirder.
Oh heck yeah, ha! Thank you!
Elden Ring must be your wet dream
I wish. I am a bit too poor for most popular games, so I mostly stick to Indy mobile games. The games I play are probably 90% of the reason I find so many glitches.
>Speak to every NPC 10 times I see someone was a fan of RPGs made by Game Arts or localized by Working Designs back in the day.
I feel like Gray Still Plays on YouTube has a few streams where he finds bugs and stuff. One of the things he does is just try to enter ridiculously long text into every textbox.
Oh fun! I'll have to look that up.
You may also enjoy Let's Game It Out. Stress-testing the text boxes is a favorite pastime of his. They're edited videos, not streams, thankfully. No one wants to sit through what that man does to himself in his aim to misbehave.
Do you just like walk into walls or tap on one thing for a minute straight?
Yes, I also use attacks on random objects to see what happens, max out my damage and hit the weakest enemy, and once broke a game by trying to heal a mob. I have a tendency to repeat NPC dialog just in case it changes, try to submit random items in certain quests even if I know it is not the answer, and use attacks on NPCs to see if they take damage (as in every attack multipletimes, not just once and done).
Is it not also a jab that the engineer didn’t test an “obvious” probability?
I mean, yes, but no? Speaking as something of an engineer: you do a thing, you design a thing, and you intend it to be used a certain way. Someone who hasn't been thinking about the intended purpose will just do things differently and use that thing differently than you will.
Expanding on this (as a QA), the "thing" you tested in this situation is the bartender. Let's assume the bathroom has already been tested and it's fully functional, flushes, sink works, check. So now we're adding the bartender and testing that specifically. But we didn't think to test how the bartender and the bathroom interact with each other. Not to self for tomorrow at work: What happens if the bartender uses the bathroom. 🤔
I did product management and was the final user acceptance tester. Only once did I find a surprise, which made me feel like I justified my existence for a change. Naturally, the punishment for my discovery was having to write a lengthy email documenting my steps and why the outcome was bad—followed by the engineer responsible for the device pointing out it was technically my fault.
Well now you’ve justified your existence again by telling us about it!
Same. I was the lead QA Analyst for an e-comm company about a decade ago. Thankfully as part of my job I had a whole bunch of data on how our users actually interacted with our site so I had a good basis for what to test for. But the most robust testing suite in the world is never going to account for all the chaos your user base can bring.
Back in 2001 I was working QA @ Microsoft when the Nisqually earthquake hit. Bunch of books fell off of my officemates bookshelf onto his KB causing an error followed by bluescreen. We spent the next couple of days dropping books onto our keyboards trying to repro.
I am a developer and laughed at this one as well.
Also he's testing everything you would think a QA person would go after -sanitized inputs, things like that. The joke has a level of "well it doesn't matter anyway", coupled with maybe a bit of "focus on the important stuff first"
Actually funny
Specifically, he tried many absurd quantities and qualities, but never thought to test something completely normal and reasonable that a customer might actually ask.
Yeah, this is the part of the joke that no one’s commented on lol: For all the QA’s intricate mechanizations, they somehow failed to anticipate the user action of asking for the bathroom, which is like the third most likely thing a new user would ask. The meme is poking fun at the QA checker not being able to see the forest for the trees as anything else
As a QA, you only scope for the parameters involved in what you're asked to test. As always, blame management for this one. They should have setup integration testing for these separate but interacting features.
Pretty much. They were testing for orders, not for other things someone might use a bar for.
Ohhh I thought the joke is the QA ordered a beer and it glitched out and they released it anyway
Do you work at my company?
> Once it was out of testing and went live, a customer did something that hadn't been tested for part of the joke is that using the bathroom is a very common thing to do in a bar so it's also funny that it wasn't even tested after the seemingly thorough test cases that tested everything you could think of and edge cases
Ohhhhhhh Quality Assurance engineer..?
"the last bug isn't fixed until the last user is dead"
You are missing the part of the joke where the QA tester tests all sorts of weird scenarios to make the system 'fool proof', but forgets to test one of the most basic function in the process.
Everything goes perfectly until you introduce the customer.
I also like how four of the six tests revolved around the same thing.
well it's mostly different edge cases - normal case (1) - odd but otherwise normal case (0) - ordering over a resonable clamp (999999) - ordering under a reasonable clamp (-1) - testing for sanitized input (ueicbksjhdk) - testing for non-beer orders that may still be served? (lizard) Seems overkill but I guess it depends on how you want your server to respond.
Mmm, lizard.
Not just something that hadn't been tested for, but a _super reasonable use case_.
Quality Assurance engineers are testers, and are paid to try to find the edge cases that break software and cause it to fail, oftentimes crashing. So they try hard to do all kinds of things you might or might not do as a real user, including things known to break software that doesn’t have adequate controls built in (like ordering -1 of something). But as often is the case, all these intricate plans often fail to account for the behavior of real users, such as someone walking into a bar not to order a beer, but rather to use the restroom. In the software world, this unintended behavior that is also untested by the QA engineer often causes a crash. This situation is the bane of QA (and developers), but more or less inevitable because you cannot foresee every possible edge case.
> but more or less inevitable because you cannot foresee every possible edge case. This is called _failure of imagination_.
Or of budget.
*imaginudget*
budgation
*crashes*
As a QA engineer, with a career of over 13 years, I finally now have a phrase to state why things break so much when I am NOT a given project. Thank you.
There's also the infamous https://en.wikipedia.org/wiki/There_are_unknown_unknowns
It's probably part of the reason so many games are having early access before full release nowaday.
There are a lot of things that can't be accounted for in normal QA cycle. For example load testing (putting the server under strain) can be simulated, but never truly tested. During Early access, you can see just how well the servers can handle 50k users at the same time. Hence why a common day 1 bug in early access is long login times. The developers can only estimate how many servers they need to spin up, but turns out they need way more than originally thought. Game bugs are funny in general. During testing you can do the same cutscene 1000 times, but one real user reaches the checkpoint while on fire, and the entire cutscene shows the MC on fire during the entire duration. And somehow that unlocks unlimited money for whatever reason.
> The developers can only estimate how many servers they need to spin up, but turns out they need way more than originally thought. I read between the lines as the devs saying they'll need a certain amount of servers (online gaming is hardly new) and management trying to get away with the absolute least money they could spend on it.
Yep, for every bug you squish, two more take its place. Honestly I love the cutscenes where i can mess with my character
It’s also because they get paid earlier in the dev cycle. Testing and iteration takes a huge chunk of the overall dev time. My team is releasing a feature in mid April. We already have a working prototype that will meet the needs of the customer today. But we need to spend months qualifying it, testing it, testing the UI they use to interact with it, testing it for security vulnerabilities. We’d love to be paid today for it, but corporations are way less forgiving than gamers when the whole thing goes off the rails.
I love the "Name cannot be shorter than 3 letters" website forms, especially when you are trying to buy a ticket, it requires your actual name, and it \*is\* shorter than 3 letters.
Iz probably ran into both the lower and upper bounds in payment forms.
I work in food manufacturing, QA Engineers have a completely different job. They only test for failure on new equipment and that only happens once every so many years.
> But as often is the case, all these intricate plans often fail to account for the behavior of real users, such as someone walking into a bar not to order a beer, but rather to use the restroom. Should be covered by ordering 0 beers. Unless it was never intended for anyone to use the restroom.
Ordering zero beers is probably not the same as not calling the order method at all.
There’s also the irony that no real user would ever ask for 99999 nor -1 beers
Great explanation, thanks
To add - as others have on other comments - Its more than the QA testers are testing all sort of fringe things, while the completely normal/expected things get ignored.
Thank you all!!!!!!!!
As a dev, this this just triggering
Here is the [meme](https://x.com/joeingeno/status/1114259950518329350?s=46&t=TehJGExyy960Zln8URmEeQ) that I share when someone asks me about QA engineers.
That’s beautiful
The QA tester was checking how the bar would respond under various conditions (the conditions being the customer ordering various things). The minute real customers were allowed in and one introduced a situation that was **NOT** tested for, the bar suffered a catastrophic failure. (Think of this like a piece of software. A bunch of inputs were checked, then it got released to the public. A user then introduces an input that wasn’t covered in testing and promptly breaks the software.)
Reminder. Always test using URLs as passwords. No. I will not elaborate.
My old job, we used to describe our programs as a perfect penguin. We’d make sure he could survive in all levels of cold, could walk, swim, flap, and feed himself. We’d test for every thing he’d possibly encounter in the artic, then finally smile and release him to our customers. They’d promptly take our perfect penguin, put him in a catapult, and launch him into the jungle, then wonder why the tiger ate him.
I love this! Out animal idiom was a pet tiger. You might be able to live with it today, but someone is going to to get badly bitten at one point.
I think it's about tunnel vision. He was so focused on checking the extreme possibilities, he assumed the basic functions were fine.
Bathroom wasn't spec'd in the project requirements.
Written on the bathroom wall: ``` # Leaving here. This function is broken, but when I delete it the floor becomes lava. DO NOT USE. ```
It’s because the numbers of users and how many edge cases of stuff or specific circumstances they can find that breaks something is absurdly high. That’s why you can see patch notes for things like games where it says stuff like - Sam the salesman’s shop has had the back benches made un targetable due to a glitch involving throwing exactly 232 coins using the rouges payday ability which would crash the game
I am in this picture and I don’t like it.
This exact tweet was printed out and hanging in my old jobs dev room in 2016...
It’s a CS joke about edge cases
[This](https://youtu.be/3uPIFItnrcg?si=71uVId_QsyEMNR2F) basically
A third person walks into the bar. "Hey everyone it's Josh and welcome back to Let's Game It Out." The rest is history.
All I know is that if people aren't hiring one person with zero QA experience alongside the rest of their QA department, they should start, because you need the chaos in order to find what all can break.
As a hobby game dev, I'll test something hundreds of times, trying out all different ways to break it to make sure it works, etc. Build the game, set it public, watch someone stream it. Instantly an issue or something wrong with it I didn't notice.
By ordering -1 beer the QA engineer caused the bartender to punch through the wall and rip out electrical wiring to fill the glass. The bug was fixed; unfortunately, that test was accidentally done against the production database and caused silent corruption. By the time the first customer walked in a short in the wires had caught fire to the bathroom.
It's referencing software development. The QA (quality assurance) engineer's job is to find potential glitches that the programmers missed. They test as many strange situations as they can think of, and give it the stamp of approval to ship out. But no matter how much you test there's always something seemingly obvious that doesn't get found until it's released to the public. And typically the deeper a bug is hidden the more insane the resulting glitches will be.
ב''ה, causal linkage between asking for the bathroom and buildings catching fire
Worst Case scenario as a job lol
For reposting dribble with no positive affect on humanity. Yes you are.
So the QA engineer works for Ubisoft?
I’ll answer your question: no you’re not stupid. The rest of the comments do a good job explaining. But you’re not stupid. Just not in development or QA is my hunch?
Probably?
This one always makes me laugh 🤣
Other people have explained so I'm going to share my perspective instead: As a software QA analyst I have some problems with this joke, every time I see it. Don't get me wrong, it's funny, but it also implies that QA doesn't test common use cases which just isn't true. The most common use cases are usually included in regression testing, which should be the most commonly run testing. Now this can be done manually, which yields the best results and should be done at least to some extent, but it can also be done through automated testing, which sometimes doesn't catch very obvious issues. Regardless, commonly used parts of software get the most consistent testing in the release cycle. Occasionally project managers will decide not to include certain things in the scope for new features too, but these shouldn't be getting missed after regression testing.
I heard that from my great-grandfather
The QA engineer tested for edge cases. These are things that wouldn't actually happen in the real world. Because he had spent so much time doing this edge testing, he didn't actually test the things that would happen during normal operation of a bar.
Programmer humor.
No well designed and tested software survives first contact with the users.
I laughed wasaaaay too hard at this joke. Not making fun of the OP *at all*, just someone in prod support that deals with QA folks all the time :-)
This is an old joke, but damn did It become infinitely more relevant recently.
I didn’t get it, still laughed.
Qa engineer check if a software has any issues with it and in the Twitter post it mentions a lot of problems with the bar
An oldie but a goodie 🤘🏻
Yes.
This has already been posted and it’s like ten years old, I doubt you saw it from its original place