Detailed Error Messages

Maven (famous)@lemmy.zip to Programmer Humor@programming.dev – 991 points –
77

You are viewing a single comment

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?

Being prepared for the eventuality, knowing the consequences and deciding what to do about it before it happens for a user.

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!

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.

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

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?