Where a Redneck Jew, a Hispanic Catholic, and a Computer Geek write about Gun Rights, Self Defense and whatever else we can think about.
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Brilliant.
Oddly enough, our legal system works like this as well. That is how BLM riots fit in the “free speech” hole, while parents addressing their elected school boards are forced through the “domestic terrorism” hole.
That is also how guns that LOOK scary fit through the “machine gun” hole.
I’ve seen QA testing like that in real life.
The conversation normally goes something like: We NEVER do X, we always do A, then B, then C.
System is in production and the database is seriously messed up.
“Tell me exactly what you did.”
“We were at B and we noticed a problem. So we went back to A. But because we *knew* that the next step should have been C we went directly to C, skipping step B.”
The client will always try and put the piece through the square hole if they can manage it.
And I’ve had the client scream at me when I stop them from putting arches through square holes.
The main reason I enjoyed this is that QA is right, as it is in the example you gave. If you don’t want a customer to do Z, check for Z and reject it.
Since the role of QA is to break stuff the devs need to make their stuff reject incorrect input. The thing is if there’s an unhandled corner case that breaks the application someone is going to find it and it’s better that QA finds it before release. Otherwise you get stuff like Teslas crashing into fire engines, or 737s crashing into the ground.
One of the things I teach the junior software engineers is “if your system crashes because of an invalid input from outside, it is always a product error. ‘But the input was wrong’ is never a valid excuse.”
That’s very obvious for safety-critical systems like MCAS, but it applies to every product.
I’ve seen that GIF before, and it still cracks me up.
Several years ago, when I was working product support for a popular RMM software, we used to have internal “Bug Bashes” to ferret out code and UI errors for the Devs to go back and fix. Rewards were given for each bug you found. One go around I found three bugs and wrote up a report for each detailing how I found them and what inputs I used to allow the coders to see how I got there and confirm the issues.
The manager of the Dev team personally came to my desk, with my supervisor in tow to thank me for finding the errors. Sometime later I found out the errors would have caused serious production delays and customer issues if they had not been rooted out and fixed. I got a tidy bonus and a nice certificate. The coder who was responsible for the errors was reprimanded and eventually left in disgrace.
A year or two later the Dev Manager moved on to other things. They stopped having Bug Bashes because the new Dev team manager thought they were too demoralizing to his coders. Too many mistakes were being found, documented and reported back, making the team (and him) look bad. They had taken on the outlook of making rolling updates to cover the bugs as the end users found them.
I lost a lot of respect for the company after that and switched out of support as soon as I could.
Dilbert covered this approach:
https://i.stack.imgur.com/bQOvF.png
Two great books that I wish had been available early in my software engineering career, because they served me so well once I discovered them:
https://www.amazon.com/Inmates-Are-Running-Asylum-Products/dp/0672326140
https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/1472439058
As a retired QA person, I have seen that you have to design the process to reject bad input. It is guaranteed that sooner or later some idiot end used will find that flaw if you don’t catch and mitigate it.
What is really frustrating is when the customer is the government and you are required by contract to use their designs and processes, no matter how flawed. And they sure don’t like it when you point out the flaws.