See, you just set the bar so low. Being able to save isn't working well, it's just working. And I have held the title of QA in the past. It is in part how I know these things. And in the last 5 years or so, companies have been laying off QAs and telling devs to do the job. Real QA is hard. If it really mattered you would have multiple QA people per dev. But the ratio is always the other way. A QA can't test the new feature and make sure ALL the old ones still work at the rate a dev can turn out code. Even keeping up on features 1 to 1 would be really challenging. We have automation to try and keep up with the old features, but that needs to be maintained as well. QA is always a case of good enough. And just like at Boeing, managment will discourage QAs from reporting everything they find that is wrong. Because they don't want a paper trail of them closing the ticket as won't be fixed. I've been to QA conferences and listened to plenty of seasoned QAs talk about the art of knowing what to report and what not to. And how to focus effort on what management will actually ok to get fixed. It's a whole art for a reason. I was encouraged to shift out of that profession because my skills would get much better pay, and more stable jobs, in dev ops. And my job is sufficiently obscure to most management that I can actually care about the users of what I write more. But also I get to see more metrics that show how the software fails it's users while still selling. I have even been asked to produce metrics that would misrepresent the how well the software works for use in upper level meetings. And I have heard many others say the same. Some have said that is even a requirement to be a principle engineer in bigger companies. Which is why I won't take those jobs. The "good enough" I am witness/part of is bad enough, I don't want to increase it anymore.