Yes, regression testing--making sure bugs you've fixed don't return--is a standard part of QA. I did volunteer QA for Mozilla in college a good 20 years ago (god that number is horrifying) and they had an ever-growing suite of regression tests. Mostly for rendering/layout or JavaScript engine bugs, since part of reproducing and proving you'd fixed those was creating a minimal test case. Which you could then easily throw into the build pipeline.

Bugs are a fact of life, but burning time and money to fix them only to have them return is the worst case scenario. Organizations that care about quality are definitely investing in regression testing. Unfortunately a whole lot of orgs give QA zero respect and offshore it to the lowest bidder, if they do it at all. It's absolutely insane to me that Apple wouldn't have regression tests for jail breaks, some of the most high profile bugs in history.

You can fairly criticize Mozilla for a number of things these days. But they had a very robust QA and CI/CD setup in the early 2000s with tools like Tinderbox and Bugzilla. When DevOps came around and popularized it I was like wait, people weren't already doing this stuff??? Turned out I had been living in a bubble and that was not the norm at all.