Drill Sergeant School of Management
I've never met a software engineer, or any employee of any business, who said: "The best boss I ever had really stuck out in my mind because of the way he would yell at people when they screwed up." I myself have never considered a boss to be an excellent manager because of the way they embarrassed The Guy Who Screwed Up. Now, I've never been an executive. If I had, I would probably be pleased at the way such a manager was whipping the plebes into action. But I absolutely guarantee that this management style is not going to win any loyalty points or motivate the team.
I myself have made plenty of mistakes in my career. But the best boss I had did not rake me over the coals for making a mistake. He discussed problems in his office, with just me or one or two other close team members. He covered for me while I fixed things, and together we worked to make sure everything was ok, both technically and business-wise. He was willing to do that because I also delivered really good results for him, and getting on my bad side would not have been a career win for him. Other people on our team screwed up too. But I don't recall him calling any of them out in public (team meetings, in open areas, etc.). He knew how to have those conversations in private. He didn't always succeed. But when he ended up with a weak performer on his team, he usually managed them onto another team. If someone was really bad, he would do one of the hardest things a boss has to do and fired them. He didn't fire many people, but the people he did fire were never missed.
Society is Evolving
We have to be honest: society and culture has evolved a lot in the last 30 years. The changes are almost mind-numbing. Things that were considered perfectly acceptable 30 years ago will get you on the losing end of a lawsuit today. I'd like to think that things are generally getting better, but reasonable people can disagree. I myself have changed a lot over that time, and I certainly said and did things 20-30 years ago that 2020's-Me would not consider professional or acceptable. There was a time when I would say that calling people out precisely for their mistakes and technical failures is a perfectly reasonable, even morally good thing to do for the health and success of the team and the business. But having been on the business end of that policy on more than one occasion, it is clear that younger-Me would have been an absolutely terrible boss.
Men and Women are Different
This is going to ruffle some feathers and trigger some righteous indignation, without a doubt. And when I say this, I mean it in the strictly statistical sense (I believe the means and variances are different, but the distributions still have considerable overlap). I think men relate to men differently than they relate to women for a whole host of reasons, from biology to culture to religion to country of origin. In particular, I think men are much more comfortable competing on a raw level and dealing with each other harshly. And I think they feel entitled to this behavior because so much of society signals that this kind of behavior is not just tolerated, but accepted. Imagine if Will Smith had walked onto stage and slapped Halle Berry. We would be having an entirely different national conversation right now. There would be virtually no debate about whether such a thing is acceptable or appropriate. And yet, there is debate. Because one man slapping another man in public for an obvious slight is right on the borderline of what we consider acceptable. And that results in the massive controversy we see playing out in the twittersphere. And if it had been a woman slapping another woman, we would be having yet a different kind of conversation, with different emotional baggage and moral significance attached.
All that is to say that "software bros" have a pretty broad tolerance for socially abusive behavior within their ingroup. And if there is even a parallel group for women in software, it almost certainly has a lower (even much lower) tolerance for that same behavior. I mean, we could say that the gamer community has no overlap with the professional software engineering community, but the statistics would make an utter hash of any such fantasy. And look at just how toxic typical gamer culture is. I would say this is one area where, socially speaking, we have somehow managed to devolve. I don't think gamers were nearly this bad 30 years ago. And yet, I think it is equally fair to say that 30 years ago, the gamer community was even less welcoming to women.
What I am getting at is that the "equality" of treating a female colleague like a male peer is "morally good" from the framework of "gender blindness". But it is predicated on the presumption that the values accepted by an all-male group are appropriate for a mixed group. And I think this is where the fault lies. Clearly, women who aren't invigorated by a public humiliation fail to accept this weeding-out of weakness that may be perfectly acceptable to an all-male group. But more importantly, all-male groups often accept a certain level of social toxicity because members do not want to be perceived as weak or less masculine. In fact, many members of such groups would prefer to have a more socially neutral, less toxic culture, but are unwilling to say so publicly for fear of social rejection. Especially in a highly competitive for-profit software business, there is nothing to be gained career-wise by calling out a toxic competitive culture for what it is and demanding something more pro-social.
Many people have already pointed this out, but what your female colleague should have told you is that your whole management style is needlessly aggressive, and you should rely on positive reinforcement to achieve your desired results rather than public punishment and humiliation. What I am suggesting is that your team didn't demand this change before, because as a group of men, there were strong sociological forces pushing against any such inclination.
There is still the question of whether you treated your female engineer unfairly. To answer that, you should consider the mistakes made by your other engineers and ask yourself whether you called them out as forcefully and as often. It's difficult to make such self-reflections in a truly accurate manner, because we are clouded by our own biases. There is the question of whether you can even remember the mistakes made by your other engineers, as you may have filed them away as less interesting at a much higher rate.
I think the ideal approach would have been to act cool when you found out that the engineer (let's call her Alice) didn't run her tests, but then call her into your office for a meeting. "So, Alice...everyone else on the team ran the tests against their code and nothing came up. How did your test results look?" ... "Oh, really? So you don't think it's important to run your tests? Ok. I'll play ball. Where do you think we should look for the problem next?" ... "Look, Alice. I know you have a lot of confidence in your code. I have a lot of confidence in your code. But if we circle back around in a week and find a problem in your code, there's not much I can say to my boss when he asks what the holdup is on the release. If you want me to go back to the team and ask for a new brainstorming session on next steps, I'm happy to do that. But if the problem turns out to be something you could have discovered already, then there's gonna be blowback that I am completely unequipped to block. I hope you understand me."
At some point, you got her to run her tests and find the problem. Great! Now you need to fix the problem going forward with another meeting. "So, I'm glad we found the root cause and fixed it! Great job on that! What do you think we did well, and where do you think we could improve?" If she takes responsibility for her actions, then you can just say: "Great! I'll be looking forward to the results of your test runs on the next release!" You need to manage expectations and set an unambiguous bar for quality that she understands. If she doesn't take responsibility, then just say something like: "Well, I gotta do a post-mortem with my boss on Friday. If Bob (most angry male peer of Alice) were writing this up, I have a pretty good idea of what he'd say." Look at her out of the side of your eye with a knowing frown. "But let's say you were in my shoes. How would you write this up?" If she still acts clueless or irresponsible, then you know you need to manage Alice out of your team, and possibly out of the company. But the point is that if you are willing to give her some cover to fix her mistake, she will be far more grateful to you than if you whip her in public in front of her peers. She'll likely be much more diligent in the future, especially knowing that she's already burned some political capital of her own and yours. And if she isn't, then you actually have a much stronger case for getting rid of her than just humiliating her in front of the team.
But taking a step above that, I'd say there were deeper problems. Why weren't all the tests run automatically? I know that unit testing and continuous integration weren't fully industry-standard back in the 90's, but if anyone were on the bleeding edge, I would hope that a top Fortune 500 tech company would be one of them. If the problem was that a release was held up because some tests weren't run, then the problem isn't a female engineer. It's a failed testing culture, which is a team-wide (or org-wide or company-wide) problem that should be addressed at a wider scope. And this is the problem with making failures personal: it takes away from the focus on the whole team improving processes to reduce mistakes. When you have a culture of identifying problems as a team, without assigning blame (i.e., an agile-style retrospective), then the whole team is better positioned to finding solutions and fixing the holes. You can still follow up in private with engineers that are consistently under-performing. But relying on those people to fix their own performance problems is a strictly inferior solution to asking the whole team to shore up any weaknesses.