order to verify that functionality that worked correctly before the change still works correctly after the change. For example, developers fixed a defect. Aside from checking that the steps described in the defect report do not lead to a problem anymore, tester has to make sure that adjacent areas are not broken by the fix. The reasons why you need to test for it are quite different. System may have similar functionality in another module that developer overlooked. Or a core component was fixed and most of the functionality built upon it is under risk. To make sure no new issues are introduced, we do regression testing.
The same is for system functional testing. Imagine, you've got a new build and developers tell you that they have introduced a new functionality. Besides testing for new features, you have to do regression testing for the old functionality that could be affected. Where to start?
As usually in testing, we start from collecting information. Information helps taking on right decisions. Ask developers where they recommend focusing attention while doing regression analysis. Unlike you, they know code structure (or at least pretend to know it☺). Based on this knowledge, they may point you into the right direction in your search. Do not rely on guesses only. Way too often applications fail in the parts a tester would never imagine as being connected to a change.
If you are lucky and you have working automated tests, then your regression analysis will be as simple as it takes to decide on executing all the tests .
Testing still requires quite a bit of problem‐solving skill and creativity on your side. This is why it is still so much fun ☺
Do not stop thinking! Never!