Regression testing are tests that are executed recurrently against certain events. The goal is to verify that what was working before is still working. That is, we do not have to return the product to its previous version.
But ... why could there be changes? Because we work with systems. A system is a set of related parts that interact with each other to achieve a goal. Any change in one part of the system affects another. When developers fix a defect or add an improvement or new functionality, they are modifying a part of the system. This may impact another part that was already working well. Then, depending on the magnitude of the changes and their impact, it is appropriate to do regression testing.
Doing regression testing involves running tests that we had already run before. How do we choose the tests to run? The answer is simply: applying a criterion. And that criterion could be the most used scenarios, the most critical functionalities, the ones with the greatest impact, etc.
Before finishing, I add an additional reflection ... these tests are usually a bit boring because they always involve running the same scenarios (and the fun of testing, at least for me, is using creativity to think of new scenarios). Doing boring tasks makes us more prone to making mistakes that could be avoided if we automate these tests.
Regression tests are candidates to be automated, not only for this but for other reasons that I also tell you in the video.