You're viewing a single thread.
At my job, we have an error code that is similar to this. On the frontend, it's just like error 123.
But in our internal error logs, it's because the user submitted their credit card, didnt fully confirm, press back, removed all the items out of their cart, removed their credit card, then found their way back to the submit button through the browser history and attempted to submit without a card or a cart. Nothing would submit and no error was shown, but it was UI error.
It's super convoluted. And we absolutely wanted to shoot the tester who gave us this use case.
Better the tester than a user.
Whats the difference?
As of now, I consider you an enemy
Are you from microsoft?
Being prepared for the eventuality, knowing the consequences and deciding what to do about it before it happens for a user.
Different mindset. A user doesn't want to find bugs but get shit done.
I'd argue that is maybe 95% of the time. People get bored.
Brand reputation?
Users are dumb, testers are assholes.
Sometimes testers are also dumb. Most times.
And we absolutely wanted to shoot the tester who gave us this use case.
Why? Because he tested well and broke the software? A user changing their mind during a guided activity absolutely is a valid use case.
I think they meant shoot in like a friendly way. You know, happiness bullets!
Oh, THAT's what "friendly fire" means!
hey that tickles!
Like how I always say to my friends, "Look at me again and I will fucking murder you and rape your family dog".. it's just in good fun.
It's likely a difference of emotion compared to logic. Emotionally they'd think "Damn it, now we need to check for such a weird specific edge-case, this is so annoying" while logically knowing it's better the tester caught it.
Give that tester a raise bro
This makes want to become a tester. It scratches my evil itch just the way I like it.
there's three qualifications to being a testor:
Finding stupid ways to break shit, Being able to accurately explain how you broke shit, and being likeable enough that breaking their shit doesn't make the devs angry.
Being able to accurately explain how you broke shit
This is the most important part. Or look at systems like SpiffingBrit and Josh (Let's Game it Out) look at games
Josh does mostly stress testing though
That too, but also lots of glitching through walls and, most importantly, "doing everything as wrong as possible"
Don’t shoot the tester shoot whoever wrote the code (or the framework / library) that got you into this situation in the first place.
If that broke the software it sounds like you have a very good tester.
What about the test case where I’m using the browser’s dev tools to re-send http requests in random orders?