A QA tester walks into a bar,
orders a beer,
orders 2 beers,
orders 0 beers,
orders 4294967296 beers,
orders -1/12 beers,
orders HGdIhFNPiHPWUDmUfWIFi beers,
orders a zebraFirst real customer walks in,
asks where the bathroom is,
the whole bar catches on fireWorked in my bar
He didn’t order null beers? What a fraud
Workaround: insist that customers piss in the beer, citing exceptional flavor-add as a positive side effect. Next version, no budget for a full bathroom, so increment beer mug size to accommodate cross-stream scenarios.
My favourite one was when I asked the user “can this happen?” (Some value being negative) and they reply “no never”.
Then, of course, I get an occurrence the day of the live demo with the user and her boss.
I ask again, “uh, so is this normal? Has it ever occured before? Because I asked you if it could happen and you said never.”
Now the boss replies “oh, we meant it’s extremely uncommon. Almost never happens”.Turns out it happens once every few months, amongst hundreds and hundreds of transactions.
So I gently explained that the computer doesn’t care how often it happens. If it can happen, I need to code it in otherwise things go wrong!
Thankfully I had planned the eventuality, so I had a nice error message, but still. A lesson was learnt that day.It pisses me off when I have to explain to lead developers that we do in fact have to care about things that are “unlikely” to happen because they can in fact happen and when they do they will cause downtime just because you didn’t want to spend 16 man hours adding a solution to the problem
Nah, it’s more:
QA: Can it be used as a catapult?
> baby starts crying
YEET
Day before release showing an engineer working on a different project: “Wait, isn’t there a reason that car seats are rear facing for young children and not forward as you have it? Did anyone check on that?”
Lol, “dev testing”.
It’s the kind of testing my colleague would do. “well, nobody would be idiotic enough to enter something weird when they are asked for a number”. And so he’d only write tests for numbers. That kind of stuff.
The unit tests I’m looking at in this latest jobs are some primo “dev testing” bullshit. Their sole purpose clearly was to be able to say “we unit test our code in our pipeline and it all passed” and that’s about it. Ugh.
